10 Most Common Anti-Patterns Every Software Engineer Must Avoid!
The extension and maintenance of a system requires a good software structure. Due to the complex nature of software development, the system structure whose architecture and design have been planned and the system structure that is developed may differ from each other. This inconsistency may result in the use of anti-patterns as a solution to the emerging problems, which contrarily causes greater problems. This article will present 10 commonly used anti-patterns in Software Engineering.
1. First things first: What is “Anti-Pattern“?
Anti-patterns are also called “bad practices”, “dark patterns”, or “pitfalls”. The anti-pattern concept has been widely used since Bell Labs programmer Andrew Koenig mentioned it in his book “C Traps and Pitfalls”. According to Andrew Koenig:
An anti-pattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn’t one.
Although there are standard design patterns recommended for solving problems in software development, anti-patterns continue to be commonly used, but they are ineffective and/or counterproductive in practice. Knowing anti-pattern concepts makes it easier to anticipate the potential problems in software development processes and take timely actions.
2. Anti-Patterns in Software Engineering
Anti-pattern examples in software engineering can be listed under five basic categories. The following graph shows these five categories with examples:
In this section, I will examine 10 most common anti-pattern examples in detail.
2.1. Magic PushButton
The magic pushbutton is one of the most frequently used anti-patterns in software design. Also called “button-click” programming, this anti-pattern is quite common in GUI (Graphical User Interface) based applications (e.g. Windows Forms Programming).
This approach entails writing the business logic directly within interface code without using abstraction. As a result, the code underlying the Pushbuttons becomes unmanageable, and the reuseability, readability, and testability of the code decreases.
2.2. Boat Anchor
Boat anchor is a piece of software that is kept or left in a project although it does not have any functionality. Typically, this is because the developer thinks that they will need it later. However, this assumption is almost always wrong.
Forgotten pieces of code can create a big question mark for programmers in the future. After several years, it may no longer be recalled for what purpose they were used or why they were even written in the first place.
2.3. Cargo Cult Programming
Cargo cult programming refers to the use of software structures, patterns, and methods without a clear understanding of what/how/why.
The developer implements the software structures, patterns, and methods that are used for a solution without knowing how they work or why they are used. This strict adherence encourages the developer to resort to the same philosophies in other solutions too.
As a natural consequence of this, the developer moves away from the problem and becomes unable to make the appropriate diagnosis after a while.
2.4. Error Hiding
Error hiding refers to catching an error or exception without displaying a meaningful message to the user and deleting the stack trace during exception handling.
Having received no meaningful notification about the error, the user naturally does not understand the problem. To avoid this, a meaningful error message should be given according to the type of end user and all relevant data about the error should be kept for debugging purposes.
2.5. Lava Flow
Lava Flow refers to the practice of keeping undesirable, redundant, or low-quality code because removing it would be too costly or have unpredictable consequences.
Some software projects start for research purposes and then evolve into products. However, these products often turn out to be a historical antiquity of code pieces whose purpose is long forgotten or unknown. This might be because the person who wrote the code has left the company or simply because the developers involved in the project do not remember the purpose for which the relevant piece of code was written.
2.6. Spaghetti Code
Spaghetti code refers to a source code whose structure is barely comprehensible and difficult-to-maintain, especially due to the misuse of code structures.
This anti-pattern usually occurs when acting outside a logical design body. This means that object-oriented language capabilities are ignored and a separate function is written for almost every business process.
The result of this is a code that is far from readable and difficult to follow. This type of code is usually created when programs are constantly updated in their lifecycles, or by inexperienced developers.
These types of codes are generally not intelligible to anyone other than their developer, and they often need to be rewritten.
2.7. God Object (The Blob)
In object-oriented programming, God objects are objects that know or do too much. These objects have many members and behaviors and can be perceived as the main class of the application. These objects bring too much complexity to the code. In addition, these objects take time to load into memory.
2.8. Copy-Paste Programming
Copy-paste programming is the production of highly repetitive code via copy and paste operations without creating generic solutions.
As a result, every change in the main code needs to be applied to wherever the code has been reproduced as well. In addition, updates can be costly, bugs can go unnoticed and the risk increases for the faulty operation of the app.
2.9. Golden Hammer
Golden hammer is a well-known solution or concept that is obsessively applied to many software problems.
It is basically an attempt to apply a solution that has proved to be successful before to new problems. However, it is not always possible to solve problems using the same methods and approaches.
This might occur when development teams are not aware of technological advances because firms want to avoid the additional cost of training, or simply because some teams do not allow activities and studies that will pave the way for individual development.
2.10. Reinventing the Square Wheel
Reinventing the square wheel refers to the failure to adopt an existing solution and instead adopting a custom solution that performs significantly worse than the existing one.
There are already standard and specific solutions to certain software problems. Moreover, there are standardized architectural approaches and structures for these solutions. An attempt to produce a solution from scratch instead of using these facilitators is called the reinvention of the wheel. In case of such attempts, the development team usually believes that the problem in question is very special and cannot be addressed with existing practices. Also, the lack of technology transfer and communication between software development teams causes this anti-pattern.
3. Conclusion
Whether you are a career-starter in software development or you have spent years in the software industry, you might have already encountered some of the anti-pattern scenarios mentioned above or even played an active role in it. Since software development processes, techniques and architectures are constantly developing and changing, anti-pattern cases are simply unavoidable. However, we can deal with these situations more effectively if we are aware of what we are facing. This article presented 10 most common anti-patterns, yet it should be noted that there are many more. It would definitely be useful to learn about them by examining example cases.
That’s all for the anti-patterns in software engineering, I hope you enjoyed it. Please feel free to leave comments and share the article with others.
References
https://en.wikipedia.org/wiki/Anti-pattern#Methodological
https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture/Anti-Patterns
https://sourcemaking.com/antipatterns/software-development-antipatterns
https://www.buraksenyurt.com/post/AntiPatterns-Ders-Notlarc4b1m
