Anti-pattern is a frequently used solution for a problem, but the one that is not good and usually has negative consequences. And it is very likely that we have all seen and made an anti-pattern several times, but have not been aware of it.

Most software developers have met in the course of their careers some design patterns, or at least they have heard of the term. Patterns are general, well known and documented solutions that are used to solve the most common problems in software development.

Anti-pattern is a frequently used solution for a problem, but the one that is not good and usually has negative consequences. And it is very likely that we have all seen and made an anti-pattern several times, but have not been aware of it.

Some of the most common anti-patterns are:

Bleeding Edge – Use of the latest technology and tools, that are, although promising, mostly insufficiently documented or still in the beta stage, and therefore pose a risk to be unreliable and have a negative impact on the complete solution. This approach is not always anti-pattern, but only when the technology or tools become mainstream or are dismissed after a certain time. Therefore, it is necessary to be careful when choosing latest technology in development, which certainly should not be avoided because of the risk, but rather closely analyzed before the use.

Vendor Lock-In – A system that is overly dependent on some external component. With this approach, any change by the vendor may require major changes and improvements to the entire software. It is possible that the external component / service stops providing services thus preventing the use of your solutions. The best way to avoid this anti-pattern is to use inter-layer between your software and external components and to integrate it with multiple vendors and to create a fail-over scenario in case some external component stops working.

Reinventing the Square Wheel – Creation of tools and functionalities that already exist as standardized solutions, whose end result is worse than the standard solution provided. This occurs in situations when developer does not know that there is a standard solution or does not know the problem he wants to solve well enough, so he cannot know how standard solution is overcoming it. This can be avoided with better analysis of the problem before attempting to apply a certain solution. This anti-pattern is often very difficult to notice, and thus to eliminate it.

Programming by Permutation – This is often referred to as “programming attempts.” This anti-pattern is probably most commonly used by junior developers. It involves solving problems by making small adjustments (permutations) on a particular code and then testing it to determine whether the software now behaves as expected. This program is the result of insufficient knowledge of the problems and common consequence are holes and bugs in the second part of the system that are the result of untreated cases.

Premature Optimization – Optimization of the system performance based on the appreciation of where some of bottlenecks could appear and not on the basis of tests and real cases after software is released in the test and production work. This approach often does not create better performance and the negative consequences can be numerous, such as complex code and architecture, harder maintenance, and often worse performance than it was prior to optimization.

Golden Hammer – The assumption that the solution that has been successfully implemented in one software will also be successfully implemented in another solution. Not all softwares are identical, therefore the tools and solutions that are applied cannot be identical, but it is necessary to adapt or change them depending on the problem that needs to be solved.

Lava Flow – Represents storing of unwanted, unnecessary and usually poorly written code, and the only reason for not removing it is that you may have unforseen consequences and costs. This code is usually written during the development process, and then it does not get overwritten before going into production. Hence the name since this code, after being released into production, acts as a petrified lava – solid, unchanging and useless.

Spaghetti Code – A derogatory term for unstructured, poorly written code, which is very difficult to maintain. There are many reasons that cause this anti-pattern, but the most common are the short periods for development, lack of experience and lack of encoding rules. To avoid this problem, it is necessary to follow the best practices for writing code and to reduce spaghetti code as much as possible.

Interface Bloat– This anti-pattern describes a situation when an interface has too many methods and classes that are implementing it, which cannot and do not know how to perform all the necessary operations and then some of the methods remain unimplemented. This anti-pattern is in direct contradiction with the “I” item in SOLID approach to programming, which is considered as best practice in the software design.

God Object – object for which we can say it knows or is responsible for too many things. They are most frequently characterized by a large number of attributes and even larger number of methods and operations. They are linked with all other components of the system and as a result even small changes to the object may have consequences for the seemingly unrelated components.This can be avoided by dividing the object into smaller units responsible only for certain, logically related operations. In some situations, God objects can also be useful, in case of, for example, microcontrollers, where the centralization of control is more important than sustainability and elegance.

Golden Plating – Adding functionalities or work in general on a project after a certain point, when these changes are not worth working for. This happens when, after fulfilling all user requirements, you continue adding new functionalities you believe the user will like.

Poltergeist – Poltergeist is a typical name for stateless objects, whose sole role is to call for a method from another class. They most commonly occur when a programmer anticipates that a certain method will have additional logic in the future, but that never happens.

Pattern Overuse – The most common mistake that a programmer makes when they first meet with some patterns. Driven by the desire to show that they have mastered a certain pattern, they will try to “embed” it wherever is possible. This happens with all major patterns such as Singleton, Observer, Factory and Strategy. It is not always wise and desirable to inject patterns. Sometimes it is enough to manage with the KISS principle (Keep It Simple Stupid). Using patterns overly can create excessive complexity of the system and lower performance.

It is very important to know about the existence of anti-patterns and how they can affect the performance and maintenance of a system. The list of anti-patterns is large and probably many architects and developers in their work have made more errors that fall into that list. There is no perfect software, and surely sometimes some mistake will occur as a result of poor judgment, tight deadlines, etc. The level of errors and their impact on the work of a solution can be reduced only with good knowledge of best practices and continuous improvement.