An anti-pattern is a proven way to shoot yourself into your foot. The term anti-pattern was coined by Andrew Koenig, and it is pretty entertaining to read about them.
The book "Design Patterns: Elements of Reusable Object-Oriented Software" (Design Patterns), published in 1994, defined Anti-Patterns as a "commonly-used process, structure or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones." In 1998, the book "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" (AntiPatterns) made the term popular. This book defined Anti-Patterns as "specific repeated practices in software architecture, software design and software project management that initially appear to be beneficial, but ultimately result in bad consequences that outweigh hoped-for advantages."
To make it short, an Anti-Pattern is a commonly used practice providing more bad consequences than good ones.
The following paragraph provides a few theories about Anti-Patterns in a very concise way. This theory is based on the book "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis". For more detailed information, read the quoted book.
Modernes C++ Mentoring
Get the invitation to the one-hour presentation of my mentoring program "Fundamentals for C++ Professionals" including Q&A
- First: 2022-10-03; 9 pm (CEST)
- Second: 2022-10-10; 9 am (CEST)
Do you want the invitation to the Zoom meeting?
AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
An Anti-Pattern is similar to a Design Pattern, a literary form, and simplifies the communication and problem description of a commonly occurring problem. Often, it is a pattern applied in the wrong context. Here are the main causes. The seven sins of software development:
On the contrary, the software design has to consider the following elementary forces when making decisions.
- Functionality management
- Performance management (non-functional requirements)
- Complexity management
- Change management
- IT resources management
- Technology transfer management
Each Anti-Pattern has the following three components:
- Name: unique name with a negative connotation
- Problem: commonly used practice with bad consequences
- Refactoring: avoidance of the Anti-Pattern or minimization of its impact
The book AntiPatterns presents three typical domains:
- Software Development: An appropriate software structure is essential for system extension and maintenance, but software development is often a chaotic activity. Software refactoring is the key to improving software structure.
- Software Architecture: Architecture focuses on the system-level and enterprise-level structure of the system. Good architecture is the key factor to the success of system development and can be achieved by architecture-driven software development.
- Project Management: Modern software engineering depends mainly on human communication. Bad project management can be highly destructive to software processes. The solutions to the Anti-Patterns are to eliminate unproductive boundaries and empower the engineers to make their own decisions.
Now, to the fun part. Here are a few Anti-Patterns. I use the classification of the Anti-Patterns book but also incorporate anti-patterns from other sources. Additionally, I present a few reasons for the presented anti-patterns.
Software Development Anti-Pattern
- Cut-and-paste programming (aka copy-and-paste): Code reused by copying source statements leads to significant maintenance problems. (from AntiPatterns). The reason may be that the company has no code reuse culture. Also, a lack of abstraction or missing communication may be the cause.
- Lava flow (aka dead code): Dead code and forgotten design information are frozen in an ever-changing design (from AntiPatterns). The emphasis lies in the development of new features. There is no time for code refactoring.
- Onion: new code is wrapped around the old one. It is often easier to add an additional layer of abstraction than to refactor the software and improve its internal structure.(https://de.wikipedia.org/wiki/Anti-Pattern)
- Swiss army knife (aka kitchen sink): The One-Tool Wonder is a universal solution to all needs; a panacea (from AntiPatterns). This Anti-Pattern is strongly related to the golden hammer syndrome.
- Golden hammer: (aka head-in-the-sand) A Golden Hammer is a familiar technology or concept applied obsessively to many software problems (from AntiPatterns) A lack of knowledge of alternative strategies is the main reason. Also, the previous solutions worked out very well and are applied once more.
Software Architecture Anti-Pattern
- The god class (the blob): A "God Class" is an object that controls way too many other objects in the system and has grown beyond all logic to become The Class That Does Everything. (https://wiki.c2.com/?GodClass). It's often easier to just add a member function to a class than to make a design decomposition.
- Spaghetti code: Spaghetti code is a pejorative phrase for unstructured and difficult-to-maintain source code. (https://en.wikipedia.org/wiki/Spaghetti_code). The obvious reason is the overuse of
GOTO statements, exception handling, or deeply nested
if-else structures. Lack of abstraction and architectural decomposition is the main cause.
- Big ball of mud: a software system that lacks a perceivable architecture (https://en.wikipedia.org/wiki/Big_ball_of_mud). A typical reason is a time and feature-driven design.
Project Management Anti-Pattern
- Brook's law: adding manpower to a late software project makes it later. (https://en.wikipedia.org/wiki/Brooks%27s_law). New people slow down the development process because they have to be trained by experienced developers.
- Death march: a project that participants believe is destined for failure or that requires a stretch of unsustainable overwork (https://en.wikipedia.org/wiki/Death_march_(project_management). The company's culture is based on control but not on trust. Contrary opinions are not accepted.
- Mushroom management: "Keep them in the dark and feed them full of shit.” In some architecture and management circles, there is an explicit policy to keep system developers isolated from the system’s end users.(from, AntiPatterns) The company's culture is based on control but not on trust.
In my upcoming post, I will write about classic design patterns. First, I write about the creational patterns
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Evangelos Denaxas, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, and Wolfgang Fütterer.
Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, Ralf Abramowitsch, John Nebel, Mipko, and Alicja Kaminska.
My special thanks to Embarcadero
My special thanks to PVS-Studio
I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.