# Anti-Pattern > Anti-patterns are 'obvious, but wrong, solutions to recurring problems'.[^1] An anti-pattern is a common response to a recurring problem that is ineffective and counterproductive. While it might seem like a good solution at first, it ultimately leads to poor results, inefficiency, or even greater problems in the long term. Here are a few key characteristics of anti-patterns: - **Looks effective initially**: It may appear to solve the issue, especially in the short term. - **Causes more harm than good**: Over time, the approach leads to complications, poor performance, or negative outcomes. - **Widely recognized**: Anti-patterns are well-known in various fields (like software development, design, or management) for their ineffectiveness. - **Repetitive**: They are often repeated because they seem logical or appealing at first glance. ## Examples of Anti-Patterns: 1. **God Object (Software)**: In software design, this anti-pattern refers to an object that knows or does too much, leading to a lack of modularity, difficulties in testing, and higher maintenance costs. 2. **Busy Waiting (Concurrency)**: In programming, this refers to a thread or process that continuously checks for a condition to be true, wasting CPU resources rather than using more efficient methods like sleeping or event-based handling. 3. **Management by Crisis (Business)**: Constantly reacting to urgent problems rather than proactively planning or solving underlying issues. ## The Art of War Dealing with anti-patterns is a deliberate process. The best way to avoid and solve those [[Anti-Pattern|anti-patterns]] rely on three steps: - learn (prevent) - detect (diagnose) - solve (heal) ### Learn The most effective way to reduce the number of anti-patterns in software is to prevent them from being introduced in the first place. The key to avoid these pitfalls is through education. By learning about the potential issues that certain designs can lead to, you are essentially "arming" yourself against future problems. > The devil hide in the details Depending on the context, almost any pattern can be considered as an anti-pattern, so it's primordial to know pros and cons depending on a specific context. Aiming for readability might maim performances, great security might alter simplicity, and memory efficiency lower the accessibility of the code-base for beginners , etc… To look for contradiction often helps to learn where an anti-pattern can be considered as a good pattern. Sometimes, anti-patterns are so commonly used that it would be bad to remove them if you target a very wide range of users. ### Detect Anti-patterns are always here. Because problems changes over-time, patterns and solutions that we deliberately introduce in our software might have been beneficial at some point in the past, but they may become anti-patterns of today. We must stay aware of this and ready to spot them. In order to detect an anti-pattern, the brain must have been exposed to many of forms they could take. The only way to do so is through training and deliberate practice. The methodology is the same for every kind of patterns, with some variation in how to practice, depending on the kind of anti-patterns and projects you aims. 1. **Define your target**: What do you aim for? Readability, performance, sustainability, security, etc… 2. **Evaluate existing patterns**: Find specific things that you think might be changed to move toward your target goal. "The devil hide in the details" it's easy to think that a solution is the right one on simplistic situations. Try to find realistic edge cases that better fit reality of the field 3. **Iterate and improve**: Once detected, experiment with alternatives. Evaluate the new design over the previous one, and in either case, you have found a better solution than the other. Document this somewhere, why you choose one instead of the other, what are the pros and cons. This is important because if context changes, it will be easier to find those patterns that are now anti-patterns to your goal and fix it before negative effects are too big. For code and programming anti-patterns, your can: - Answer questions on [StackOverflow](https://stackoverflow.com), you'll notice how difficult it is to understand some code, what is in common with hard to debug code and design - Practice coding kata such as the [Gilded Rose Refactoring Kata](https://github.com/emilybache/GildedRose-Refactoring-Kata) - Pick-up any project, fork it and try to find those anti-patterns ### Solve ## Example ### In Python ```python # Don’t for i in range(len(stuff)): do_stuff(stuff[i]) # Do for obj in stuff: do_stuff(obj) ``` --- Bibliography: [^1]: Budgen, D. (2003). [_Software design_](https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225). Harlow, Eng.: Addison-Wesley. p. 225. [ISBN](https://en.m.wikipedia.org/wiki/ISBN_(identifier) "ISBN (identifier)") [0-201-72219-4](https://en.m.wikipedia.org/wiki/Special:BookSources/0-201-72219-4 "Special:BookSources/0-201-72219-4"). As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'.