Abstraction, as defined on dictionary.com, is "considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances." It's a powerful concept that underpins software reuse. When you implement a problem, if, instead of starting from scratch, the scenario can be thought of as being an example of an already-understood question, its solution can benefit from existing implementations.

Abstraction is a powerful concept, but it carries dangers as well. The first is those who become so enamoured with the idea of generality that they design with the goal of re-use and framework construction alone, rather than remaining focused on the concrete problem at hand. The second problem occurs when said folk have their abstract solution complete, they feel compelled to force it on every implementation that comes within range.

In a project I once worked on, a group of eager young business analysts were given the task of designing a new insurance system. The business model behind insurance is pretty simple: the insured party is quoted a policy that involves them paying you a premium in exchange for which you, the insurer, underwrite various circumstances that, should they occur, cause some kind of loss to the insured. The insurer's role is to recompense the insured for their misfortune.

The boffins designing our system decided that this was merely an instance of the more general process of "money exchanging hands for goods and services." After they parked themselves in conference rooms with walls plastered with meaningless diagrams and charts, they emerged having decided that they would design a grand and general-purpose solution for all financial transactions. This "panacea" of theirs would not only handle every possible type of insurance policy known to mankind, but it would be customizable to all other scenarios that involved money changing hands, such as banking, accounting, and electronic point of sale. The end result was a system that, while an award-winning work of art for abstraction and vagueness, failed to do the basics of insurance without having to bump and fight its way through the lower layers, delivering poor performance and a badly fitting user experience.

As the cause of such overzealous design I wonder whether programmers have an atavistic desire to find some kind of ultimate software truth. Much of twentieth-century physics was dedicated to such theorem, consolidating first magnetism and electricity before moving onto gravity. Grand unification attempts occur in other disciplines - mathematicians attempting to reduce all number theory to fundamental and irreducible truths or the biologists' desire to classify living things into taxonomical trees and genus. Do software architects feel compelled to follow this scientific path, looking for shapes in the dark or patterns in the clouds where none exist?

The second danger posed by the uber abstraction crowd is that having designed their perfect solution, they now need to nurture and promote their baby, wielding their shiny hammer at every screw, bolt, or rivet that comes within range.

"Aha, you're building a JMS server. That's just a message protocol; I already have one of those that can handle everything, so all you have to do is adapt to me and write a wrapper to my API."

The problem with this solution is that, as an implementer of the abstract framework, you have to wrestle and bridge the impedance mismatch. Your code is now concerned with how to provide a JMS interface on something that was built and optimized for another kind of message protocol. Through loss of fidelity, the end result looks and behaves like a race horse wearing rollerblades and fed with gasoline. It does the job of moving on four wheels, but clumsily and without the reliability and grace of an internal combustion engine-powered car that the original spec called for. Examples of such applications occur all the time, from those who believe that e-mail is merely a type of document for which all their singing, dancing, jumbo jet document management software can be tweaked to have an inbox and outbox, through the "I love XML" bumper sticker brigade who believe that any kind of data sent over a wire should be a W3C-compliant XML document object model when simple serialization or a basic text message would have sufficed.

For the user of the application, just as the rollerblading horse is likely to neigh from time to time, behavior and functionality from the underlying abstract layers bubble to the surface. Your messaging application throws SAX parser errors at you when things go wrong, or your e-mail product tells you that document variables aren't set correctly. The terminology of the thing the user is concerned about, the message or the e-mail, is lost as one of the layers of abstract framework code that underpins their application rears its ugly head. Joel Spolsky coins this kind of behavior Leaky Abstraction (www.joelonsoftware.com/articles/LeakyAbstractions.html). No matter how much wallpaper or perfume the developer used to massage and beat the abstract framework into shape for your application's implementation, at some point the abstract layers are going to rear their head as the horse needs to poop.

Alongside the opening dictionary.com definition of abstraction, which proclaims the benefits of generality, is an ironically appropriate alternative usage: "an impractical idea; something visionary and unrealistic."

Software should be built with the goal of solving a specific user scenario. In building the solution, you should make the overriding goal high-performance combined with fitness for purpose. By using as few underlying layers as possible, the number of project and physical dependencies should be kept to a minimum. 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.