Antipatterns in software development: definition, areas of application and examples

In the field of academic debate on software development and design, that of antipatterns is certainly one of the fields that currently boasts the liveliest discussions and also the most concrete applications. In this article, we will see what the most common antipatterns are and how to recognize (and avoid) them in the context of software development and design

But what do we mean by“antipattern“?

Using the Socratic method, we might first ask what is a pattern.

Using the definition given by the Treccani, we might answer, “an established system of beliefs, behaviors, values,” ultimately a set of rules we have given ourselves that we consider advantageous for performing a given task.

Thus, by opposition, an anti-pattern is a “rule” of designing or writing code that we consider advantageous, but which in practice generates frequent application problems, worsens software usability and makes its life cycle difficult to manage.

Research on antipatterns has developed since the 1990s, when software began to become an indispensable tool in everyday life, codebases began to get bigger and the number of people collaborating on them began to become important and the staff spread across different locations, even geographically.

From this moment in history, it became necessary to identify the “worst practices” that normally occur in the application development phase and to code a set of best practices to make the code produced elegant, usable by all developers, and robust.

The antipatterns identified are a large number and span the entire spectrum ofsoftware management andengineering: they range from antipatterns on project management style, software production, personnel management, and of course code development, a part on which we will provide some examples.

The“Magic Number” (or “Magic Strings”)antipattern identifies the practice of inserting numbers or strings into code without a mnemonic representation or without being identified correctly.

For example, the line x = y / 0.9144 would be rather incomprehensible to us if not commented out, while instead declaring a constant CNST_YARDS = 0.9144 and writing x = y / CNST_YARDS would help us understand that a conversion from the metric to the imperial system is taking place.

“Copypaste programming” refers to the practice of copying code multiple times with little or no modification within the program.

On the contrary, the best practice is to be inspired by the OOO (Once and Only Once) principle and create a function for each method that you need to reuse.

A cousin of the previous one, the antipattern known as “Cargo cult programming” is the practice of copying code from various sources (e.g., StackOverflow, ChatGPT…) without really understanding what it does. Inevitably, any modification or verification on this code is impossible.

A curiosity: the term “Cargo cult” derives from aboriginal religions that grew up in the South Pacific after World War II, where some local people had developed ritual practices related to the construction of simulacra of airplanes and airstrips in the hope of summoning as divine beings the military planes and their cargoes that arrived during the war.

More specifically, the metaphor of “Cargo Cult Science” in reference to pseudosciences was popularized by physicist and popularizer of science Richard Feynman in his commencement address at the California Institute of Technology in 1974.

Literally “input huddle,” the“Input Kludge” antipattern is the practice of not properly validating inputs according to what is in the specification.

Especially in systems with many users, input validation is a vital practice because users will always find ways to “kludge” applications in unintended ways; to avoid this, it is good to always check and “sanitize” program inputs.

The practice of “coding for exceptions” is particularly insidious because if everything becomes an exception, nothing is an exception.

The result gives the idea of robust software that is always up and running, but is actually prone to errors and malfunctions that are often indecipherable, since in a sea of exceptions it is extremely difficult to figure out which one caused the problem.

The term “error hiding” refers to the practice of not showing an appropriate message to the user when an error occurs or not showing an error at all.

This is typically a source of frustration for the user, who will generate contacts in support because he or she has no idea what the incorrect operation is that he or she performed, but also for the developer, who has no idea where to start looking for the problem.

Theantipattern “Not invented here” identifies the practice of rewriting an existing solution only because it was not done in-house.

A close relative is “Reinventing the wheel,” which is the practice of rewriting an existing and tested solution from scratch thinking you can do better. Instead, very often getting worse results, a case in which we talk about “reinventing the square wheel”

The so-called “God object” is a global construct with too much responsibility and too much visibility within the program.

Seemingly convenient, in the long run it becomes pervasive, and every change affects even points that should be unrelated, not to mention that the code becomes entirely dependent on one object.

It is essential to recognize and avoid antipatterns in application development because they can lead to several negative consequences on the final product and beyond, such as:

To conclude the first part of this discussion, we can suggest three readings to further explore the topic: