Deconstructing Frankenstein


One of my favorite things I do in any architecture or design course I teach is to discuss AntiPatterns— design ideas hatched with good intentions but that prove problematic over time. We’ve all seen examples of software done badly. The purpose of an AntiPattern is to document a bad solution to a common problem, explain how people can slide into an AntiPattern, and mention ways to remedy it. The point isn’t as much to say “don’t do this” as it is to say, “you probably already have this problem, you just might not have a name for it. And here is how you might’ve gotten there, here is what you might do to prevent this happening in the future, and some things you might do to fix up your design.”

A Boat Anchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the BoatAnchor is a costly acquisition, which makes the purchase even more ironic. A Lava Flow is when unused blobs of code are hanging around in a system. It is characterized by the lava-like “flows” of previous developmental versions strewn about the code landscape, but now hardened into a basalt-like, immovable, generally useless mass of code (perhaps commented out, perhaps not) which no one can remember much if anything about.

Last week students at my class were incredibly inventive— they weren’t content to limit their discussion to examples of AntiPatterns that I mentioned. The new AntiPattern names are so good I want to share some of them. The first was the Frankenstein AntiPattern. It came about because too many cooks were watching the pot. Everyone wanted to contribute so they did, just not in any organized fashion. As requirements kept rolling in, people kept adding functionality in a disjointed, haphazard fashion. Oh, you want two eyes? OK. And a body. That sounds good. You didn’t say you need toes. Hm. OK, we’ll bolt some on. How many do you need? Where should they go? Everybody contributed, design coherence wasn’t a goal, and the implementation just kept rolling in requirements.

One might say that good disciplined designers should’ve detected this emerging porblem and prevented it from happening. Well, projects get hectic and sometimes things slide. But what’s nice about this story is that it has a happy ending. Frankenstein was banished after a diligent designer who couldn’t with a clear conscience keep bolting on stuff and make it work said “Enough!” and worked to untangle this mess. He employed several strategies. One was refusing to take code directly from marketing and to accept requirements and functionality via pseudo code instead of patches.

Another AntiPattern that was brought up was Rocky Road. It’s similar to the Lava Flow, but includes overloaded data fields and cobbled together or interpreted data fields in the mix. Not only is there dead code to stub your toes on, but there’s complicated data with overloaded, tangled encodings, too. The intentions were good: keep using the same schema but add more functionality to the software and keep encoding data in complex ways because heaven knows the data can’t be redesigned. But over time this system became extremely difficult to work with. The code was complex in that it had to decode and vary functionality based on complex interpretations of the data, and the data fields grew more complex and entangled in support of new functionally. Now what’s great about this AntiPattern name is that “Rocky Road” is an ice cream flavor as well as a travel hazard. What might start out as a sweet, quick fix, can over time turn into an unnavigable development landscape. I’ve seen this situation at other companies I’ve worked at and there is no quick fix. Someone or several people have to take the time to analyze the code and the data implications and to propose modest “safe” and agreed upon modifications. These repairs don’t usually smooth out all the bumps they keep the system from totally becoming unworkable. Usually there has to be a compelling reason to make deep and significant changes (think Y2K or migration to a new database technology).

Sometimes discussing AntiPatterns can be depressing. Especially when people work in places where painful examples are in abundance, and little opportunity or incentive exists to improve things. I like hearing stories where people have been able to repair design problems and improve how systems function. Even better when these efforts are supported and encouraged by informed management. If you have any AntiPattern remediation successes, I’d love to hear about them.

Lava Flows, Swiss Army Knives, and Boat Anchors for the rest of us

I’ll be the first to admit that I’m an object geek. But sometimes good ideas from the object community get lost because they are wrapped up in the mystique of objects. Consider the architecture anti-patterns described in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis or the Portland Pattern Repository.
The purpose of an AntiPattern is to document a bad solution to a common problem, explain how people can slide into an AntiPattern, and mention ways to avoid or remedy it. The point isn’t so much to say “don’t do this” as it is to say “you probably don’t even realize that you’re doing this, but it doesn’t work, and here are some things you might do to fix things.” In a recent workshop I conducted for architects working for a state agency, I presented the ideas of anti-patterns to this veteran group of developers. We had a great time identifying anti-patterns they encounter and deal with on an ongoing basis. Most of these architects were not using object technology, but they could spot good decisions gone bad when they saw them. We discussed several examples of Lava Flows, why they occurred, and why sometimes it may not even be a good idea to clean ’em up. What if your code is subject to changing legislative regulations? Arguably, it may be easier to leave in some code than always be shuffling things around. Especially if you are living with a shrinking budget and staff. On the other hand, if you can cut out bad practices and eliminate confusion of why that “three hundred byte record” is there, removing a lava flow can make it easier on the architect who doesn’t repeatedly explain how to step over it to new staff.

I’m on the look out for object biases in the way I talk about design. I’m hoping to bridge the divide between “those in the know” and “those in the know who use objects”. We have much to learn from each other.