Anti-Patterns: Watch Out for Common Development Mistakes
As this video from The Candlestick shows, it is just as valuable to learn from mistakes as it is to just focus on best practices.
Worst practices are common thought approaches to problem solving that appear again and again and get implemented by a programmer or even groups of programmers across continents and organizations. Ever heard of groupthink?
The cliché is that you learn from your mistakes, but this is a costly approach to learning. From a financial and timesaving point of view, learning from the mistakes of others makes much more sense. As a developer, it is your job to not repeat common coding misdemeanors. As a tester, it is your job to watch out for those common errors.
These mistakes are called anti-patterns—a pattern that tells how to go from a problem to a bad solution. Anti-patterns exist in all aspects of life from parenthood to rocket science. In software development they exist in approaches to programming and development processes—yes, even agile—as the video by Sander Hoogendoorn illustrates.
To get a taste of the solutions people come up with to solve problems—solutions that inevitably lead to serious consequences down the road— read the catalog of anti-patterns. Or to see another breakdown of anti-patterns in IT, check out SourceMaking. The truth is that software developers and operations staff, even experienced ones, are susceptible to designing, coding, and implementing problems into their environments as the “We’ll Do It Live – Operations Anti-Patterns” video illustrates.
The Candlestick presentation describes some anti-patterns, such as vestigial structure pattern. This is where you are leaving code in your codebase because you might need it in the future. Seems like a good idea? No, it’s a bad idea for several reasons. Maybe you like to create a God Class where you refer everything back to this super-duper class to solve all your problems.
What about Found on the Internet? While Google is great, it doesn’t mean that the first solution that appears is the best solution for you. Maybe you are the person that relies on the Shiny Toy because this new framework will solve all your problems. If you can’t get your application working using a reliable, well-resourced framework, you have a problem.
One of my least favorite anti-patterns is where senior management allows developers to write non-core applications. Reinventing the Wheel will cost a company a huge amount of time and money. The main product offering gets second priority to writing a new bug tracking system or new shopping cart for the website.
It seems that many anti-patterns happen because individuals and groups don’t plan to spend time in Quadrant IV. Give yourself time to think—before, during, and after—about whether your solution or overall approach is scalable, easily implemented, or might fall into common patterns of bad ideas.
Do you have examples of anti-patterns in your career?
