Anti-Patterns

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.

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:

Lust
Gluttony
Greed
Sloth
Wrath
Envy
Pride

On the contrary, the software design has to consider the following elementary forces when making decisions.

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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.

What’s next?

In my upcoming post, I will write about classic design patterns. First, I write about the creational patterns

Post Views: 4,490

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, 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, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS