Tower Of Voodoo

Type: Development

Problem: Well-designed interfaces can end up buried in the basement of a tower; each floor of the tower is a badly-written wrapping layer that seems to be the result of VoodooChickenCoding. The resulting application is inefficient and poorly-understood.

Context: Developers often have to use interfaces that are new to them. They know what they want to get done, and just want to achieve that goal and then move on.

Forces:

People don't like to admit ignorance ("how do I use this interface?").
Once people have something apparently working, there is often intense pressure to draw a line under the task, and move on to the next high-priority job.
People in many companies are under pressure not to change code that is already performing a useful function. So if someone else's wrapper doesn't do quite what they want, they'll wrap it with something that does.
People are often aware that wrapping is a good thing as it adds encapsulation, but are not always aware that wrapping comes with a cost: an added level of abstraction.
People sometimes feel the need to reserve the right to change the underlying interface they're using, even if the need for any such change is not actually clear at the time of writing their code (see YouArentGonnaNeedIt)

Supposed Solution: Once your initial exploratory calls seem to have things working, make your calls into a new interface that wraps the old interface, and then move on. The next person can always put another layer on top if your interface is not adequate to their needs.

Resulting Context: The good thing is that the job is done. The bad thing is that the original interface is now hidden behind a new one which may be lacking in at least two ways: understanding of the relevant problem domain, and understanding of the details of the original interface. For both these reasons, the next developer coming along may well find it doesn't fit their needs. So they do exactly the same thing on top of the first wrapper. And then the next developer comes along. And then the next. And the next...

Rationale: "I'm simply adapting the interface to the needs of my application layer."

Better Solutions: Don't wrap stuff unless you have a good reason. And if an existing wrapper doesn't meet your needs, try to change it rather than covering it in a new layer of abstraction.

Examples: The following things often seem to be (badly) wrapped for no good reason:

Microsoft ActiveX Data Objects
Messaging technologies (Tibco Rendezvous, for instance)
Language-provided collection classes (Java's collections, C++'s STL)
Bindings between languages

Examples in Practice:

This one was sparked off by a conversation with a friend, where we realised that we had both seen a lot of code that had as many as 6 layers of wrapping around perfectly good and usable APIs: where the need for any wrapping at all was unclear.

Might this sometimes be the fault of bad-documentation or even design of the underlying API? If it isn't, sort of, self-evident, then I'm going to stick with the first thing that seems to work.

CategoryAntiPattern