Antipatterns in software development: other mistakes to avoid

In our previous article“Antipatterns in Software Development,” we have already given defined what an antipattern is, i.e., a “rule” of code design or writing that we consider beneficial, but in practice generates frequent application problems, worsens software usability and makes its life cycle difficult to manage.

The number of antipatterns identified by academic research in the field is very large and some have already been addressed in Part I; since the discussion was obviously not exhaustive, there are other very frequent antipatterns worth exploring.

“Hard coding” refers to the practice of inserting variables and configuration elements directly within the code. Apparently convenient, but each change requires recompiling and releasing the application again. Best practice of course is to place such variables in a database or configuration file.

“Poltergeist classes” are classes that exist solely to call other classes. They may be the result of a design phase done sub-optimally, a lack of directionality in a design, or incomplete refactoring. The best practice is to eliminate these superfluous classes.

Just like a dish of spaghetti poorly spliced, “spaghetti code” is code written in a fragmented and confusing manner, due to lack of guidelines, modifications without proper design, frequent changes due to quick patches, lack of communication within the development team…
The result is code that is difficult to understand, which in case of rewriting is often placed in a wrapper.
Staying with the gastronomic metaphor, the OOP version of this antipattern is called “Ravioli code,” which is code fragmented into too many classes without precise structure.

‍The “lava flow” is incomplete or improperly tested code that is released into production earlier than it should be.
This code then tends to become the basis for other code or other services, causingbasic platform instability that is difficult to go about correcting.
As a best practice, proper design and frequent refactoring help avoid this antipattern.

The term ” Dependency hell” denotes a project that has clear dependency problems (circular dependencies, overly long chains of dependencies, …), which make it difficult to trace the problems when they occur; in the Windows environment this is also referred to as DLHell.
Using package managers to resolve dependencies and breaking them down into microservices can alleviate this problem.

Similar to the sociology theory of the broken window, this antipattern refers tocarelessness in code writing, includes, for example, variable spelling errors, irrelevant function names, incorrect indentations, walls of comments, and so on.
Exactly as broken windows in a house denote neglect and allow any kind of weather to enter, this code denotes little care for the project and generates rapid degradation of the application.

The situation of “Analysis paralysis” occurs in software whose design phase remains in a limbo from which there is never really a way out.
There are many causes, from overly requirements-focused design to a lack of well-defined project leadership.
It often leads to arbitrary deadlines for releases that degenerate into development team crunches and ultimately create disruptions for users.
Clearly, the solution is to take a realistic, iterative approach to design.

Walking through a minefield is literally the end result of all that has been mentioned: the software will seem like a minefield to developers and users, where one misstep can lead to very unpleasant outcomes.
The summation of all the preceding antipatterns is that project managers will not want to make changes, developers will be afraid to make changes, and users will have no incentive to use the software because of frequent problems.

Those presented are just a few of the most frequent antipatterns, but the discussion can certainly be deepened. To conclude this brief roundup, I suggest three other books for further insights on the topic: