System Design: Don't be So Abstract

Whether designing large software solutions or implementing an enterprise or web content management system, a proper design cycle will touch upon the topic of business process and entity abstraction.
A complete lack of system concept abstraction (e.g., a press release is at some level a content object which at some level is a base system entity) is certainly a design failure. In a recent article worth reading Joe Winchester, one of Java Developer Journal's editors, reminds us of the dangers lurking on the other end of the spectrum.To paraphrase, Joe argues that by focusing too heavily on abstraction, the end product can suffer from a loss of fidelity to the original purpose, and result in software that "behaves like a race horse wearing rollerblades and fed with gasoline."
He continues, stating that "when you're a hammer everything looks like a nail, yet when you're a software developer everything should look like a fresh challenge, not a problem to be short-changed by hacking some other problem's solution to fit."
Certainly there is a balance to be struck. Entity or business process abstraction and system abstraction layers have a well known purpose -- they can greatly enhance reuse and can serve to isolate system functions and improve both their maintainability and their robustness.
Seeking the balance is noble. Finding the balance is both an art and a science. Joe's article serves as a nice reminder for those of us enamored with design, that at the end of the day, each project has a very specific purpose and rarely is it to build the perfectly modeled and abstracted API.
However, and to quote Joel Spolsky, "As it turns out, a lot of computer programming consists of building abstractions." What Joel dwells upon in this area is his rule of "Leaky Abstractions".
This states the following: All non-trivial abstractions, to some degree, are leaky.
Or in other words, most of the time when you abstract non-trivial complexity (heh!), there will be cases where the complexity leaks through, and furthermore, good system designers and programmers are therefore going to need to understand the complexity.
A simple programming example of leaky abstraction is with ASP.NET and postbacks generated from non-form-input elements. The "leak" is when you generate postbacks via say an image click. This requires JavaScript event wiring to make the server-side code run and thus the engineer must understand that wiring in order to over-come cases where JavaScript might be disabled. Thus, the abstracted "click to run the code on the server" mechanism has leaked.
So back to the dangers of abstraction. There is no way around it. As designers and developers we utilize and benefit from it every day. Spolsky concludes that abstraction and its leaks are slowly dragging us and dumbing us down. Joe is sand-bagging the whole idea. Both positions inform and serve as great reminders for zealous designers. Sticking to the specification at hand is a mantra that is well remembered, but good designers must refine the art of the balance. [Read "The Perils of Abstraction" by Joe Winchester. Read "The Law of Leaky Abstractions" by Joel Spolsky.]