Ever since the Gang of Four came down from the mountaintop with their stone tablets, life just hasn’t been the same. They gave us 23 canonical design patterns, promising solutions to problems you didn’t even know you had. Some people thought these patterns were a way to talk about complex problems and describe tested solutions — a kind of common language that could help prevent programmers from reinventing the wheel. Other people just treated them like magic pixie dust to sprinkle over questionable code. But everyone agreed that design patterns were a Very Important Topic.
But maybe we made a mistake. Instead of inventing names to describe the common solutions coders create, perhaps we should have coined terms for the most popular disasters we leave behind. Because the only thing more popular than design patterns are these, the 23 enduring patterns of software negligence. Check them out. Are you guilty of practicing them?
The Chain of Responsibility pattern. When your code is criticized, climb the ladder of convenient excuses. The testers missed the bug. The user used the software wrong. The specs asked for it to be this way! The tools are broken!
The Forgiveness pattern. When you precede a block of indecipherable code with an apologetic comment that says
// This is legacy code or
// TODO: Fix this wonky algorithm.
The Prototype Promotion pattern. You wrote a fast and dirty prototype. The boss loved it and wants to make it a real product. But rewriting it properly ain’t gonna get you there in time. The only way to get it out as fast as they want it is to recompile your prototype and call it a release.
The Immortality pattern. If code lives long enough, you don’t need to fix it anymore. After all, changing old code is just asking for problems to appear. (Closely related to the Zombie pattern, when you keep around old bits of code “just in case.”)
The Decorator pattern. When you add design patterns to make your solution look more pro. Similar to the way you might accessorize a house with a plastic bowl of fruit, and just as inedible.
The Random Poke pattern. Your code isn’t working. Maybe change some random details and recompile? You never know…
The Clone pattern. Ctrl+C on StackOverflow. Ctrl+V in your code editor.
The Procrustes pattern. Procrustes was an innkeeper in Greek mythology who chopped the legs off his patrons while they slept, so they would better fit in his too-short beds. In software development, the Procrustes patterns is when you set a drop-dead date for your schedule, then cut the software features down to fit.
The Golden Silence pattern. Don’t let exceptions derail your code. Catch them quietly and carry on. Bonus points if you catch the base exception class to suppress all errors (which is known as the Blackout pattern).
The Apology pattern. Similar to the Golden Silence pattern, except you report the exception back to the user with a meaningless error message and stack dump. (See, we didn’t ignore it after all!)
The Retroactive Formalization pattern. Write the program first, then write the specs. That way they always match.
The Homebrew pattern. There could be libraries that accomplish what we want to do, but someone doesn’t trust/understand/know them. We’re going to build our own. Quality example: homemade encryption.
The Insurance pattern. Make the code just weird enough that they’ll always need you to decipher it. Bonus points if you leave out all your comments in the name of “clean code.”
The Special Case pattern. Bail out of whatever control structure you’re in if this magic condition/value occurs. This is a pattern of software enhancement — it crops up when you want to change an existing program as quickly as possible. Multiply the special cases, multiply the fun.
The Wall O‘ Buttons pattern. What happens when a developer improvises the user interface.
The Jenga pattern. How many changes can you make before the whole structure is teetering on the edge of collapse? Also known as the Change Paralysis pattern.
The It Came From Above pattern. This nonsensical feature must stay as-is, because it was requested from the powers that be. This pattern short-circuits all investigation and trumps all other patterns.
The Wild West pattern. Everyone picks their own validation rules and domain logic to enforce at various points. You never know how far bad data can travel.
The God Object pattern. You started with an OO design, but for some reason all the logic is now in one very special and very big class.
The Special Order pattern. Every operation works perfectly, if you use them in the right order.
The Nudist pattern. When you started, your classes kept things private. But then someone need to peek inside at something, and now you can’t look sideways without seeing the internal state of every object totally exposed and out there in the open.
The Gone Fishing pattern. When your program hasn’t crashed, but it isn’t responding either. It’s doing something, but what?
The Optimism pattern. That won’t happen. The user won’t do that. You’ll never get that kind of data. Also known as the Fuzzy Outline pattern, because you don’t have any edge cases to test.