Welcome!

Java Authors: Liz McMillan, Frank Huerta, Elizabeth White, Pat Romanski, Sandi Mappic

Related Topics: Java

Java: Article

The Perils of Abstraction

The Perils of Abstraction

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.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Steve T 11/06/06 10:44:48 PM EST

Software abstraction, or software frameworks for that matter, does not make an architecture complex. The system or the application that we are building is that which is complex and therefore we need to abstract certain aspects of it in order to minimize, or even at least manage, its complexity. Abstraction keeps the developers zero-in to the business codes rather than concern itself with say audit trail, logging, rendering of pages, handling different protocols, transaction, etc.

A multi-layered architecture is not necessarily cumbersome and slow. On the contrary, if implemented well, it improves the quality, readability and reusability of codes because they isolate system or application processes.

Joe Winchester 10/20/06 09:06:03 AM EDT

Snoobab,
Yup, you're right that fitness for business purpose is the primary concern. The point I was trying to make was that huge and cumbersome abstract frameworks often slow down the application with unnecessary layers. However, the larger category goal that speed and others fall under is one of "fitness for business purpose - does it benefit the user do their job". Things just have to be fast enough to do the job and no more, and there is the other peril developers can fall under which is they optimize it to death at the expense of having a clearly architected system. Thanks for picking me up on the point.
JoeW

snoobab 10/20/06 05:57:27 AM EDT

Umm speed should not be the primary concern, an effective and clear business fulfilling model fit for human developers is though. Code is written to be read by developers and a great simple consistent model that obviosuly fulfills business needs should be the primary goal.