Software development: Antipatterns – design patterns’ evil sister

An anti-pattern is a proven way to shoot yourself in the foot. The term antipattern was coined by Andrew Koenig and is quite entertaining to read about. The book “Design Patterns: Elements of Reusable Object-Oriented Software” (Design Patterns), published in 1994, defines antipatterns as “a commonly used process, structure, or pattern of action that, despite initially appearing to be an appropriate and efficient reaction to a problem has more bad consequences than good.”

The term became popular in 1998 thanks to the book Antipatterns: Refactoring Software, Architectures, and Projects in Crisis (Antipatterns). It defined antipatterns as “specific repetitive practices in software architecture, software design, and software project management that initially appear to be beneficial but ultimately result in bad consequences that outweigh the hoped-for benefits.



In a nutshell: An anti-pattern is a common practice that has more bad than good consequences.

In the following section, some theories about antipatterns are briefly presented. The concept is based on the book “Antipatterns: Refactoring Software, Architectures, and Projects in Crisis”, where more detailed information can be found.

Similar to a design pattern, an antipattern is a literary form and simplifies the communication and description of a commonly encountered problem. Often it is a pattern that is used in the wrong context. Here are the seven main reasons for antipatterns:

  • Have
  • disinterest
  • prejudices
  • idleness
  • stinginess
  • ignorance
  • Proud

To counter this, software design must consider the following elementary forces when making decisions:

  • functional management
  • Performance management (non-functional requirements)
  • complexity management
  • management of the changes
  • Management of IT resources
  • Management of technology transfer

Each antipattern has the following three components:

  • Last name: unique name with negative connotation
  • problem: widespread practice with bad consequences
  • refactoring: Avoiding the antipattern or minimizing its effects

The antipatterns book presents three typical areas of antipatterns:

  • software development: Correct software structure is essential for system expansion and maintenance, but software development is often a messy activity. Software refactoring is the key to improving the software structure.
  • software architecturer: The architecture focuses on the structure of the system and enterprise level. Good architecture is a key factor for system development success and can be achieved through architecture-driven software development.
  • software project management: Modern software development depends mainly on human communication. Poor project management can be devastating to software processes. Solutions to the antipatterns consist of removing unproductive boundaries and allowing developers to make their own decisions.

Now comes the fun part of this article: I will introduce some antipatterns that follow the classification of the Antipatterns book. In addition, the list includes some antipatterns from other sources and obvious reasons for the presented antipatterns.

  • Cut and paste programming (also known as copy-and-paste): Reusing code by copying source code leads to significant maintenance problems. The company does not have a code recycling culture. Lack of abstraction or lack of communication can also be the cause.
  • lava flow (aka dead code): Dead code and forgotten design information are frozen in a constantly changing design. The focus can be on developing new functions. There is no time to refactor the code.
  • Onion: New code is wrapped around the old one. It is often easier to add an extra layer of abstraction than to refactor the software and improve its internal structure.
  • swiss army knife (aka kitchen sink): The one-tool wonder is a universal solution for all needs; a panacea. This anti-pattern is closely related to Golden Hammer Syndrome.
  • Golden Hammer (aka head-in-the-sand): A golden hammer is a well-known technology or concept that is compulsively applied to many software problems. Lack of knowledge about alternative strategies is a common reason. In addition, the previous solutions have proven themselves and are used again and again.
  • Brook’s Law:”Adding labor to a late software project does so laterNew employees slow down the development process because they must first be trained by the experienced employees.
  • death march: a project that those involved believe is doomed to failure or that requires unsustainable overtime. The company culture is based on control, but not on trust. Different opinions will not be accepted.
  • mushroom management:”Keep them in the dark and feed them full of crap.” There is an explicit policy in some architecture and management circles to isolate system designers from the system’s end users. As with the Antipattern Death March, the corporate culture is based on control, but not on trust.

In my next post on the Modern C++ blog, I will write about the classic design patterns. The generation patterns will be the beginning.


(her)

To the home page

Leave a Comment