Design patterns and anti-patterns
Does a part of your system or part of your code seem to always be broken, or is it so complex that no one wants to work on it because it always breaks? If so, then you may be suffering from the bad habit of anti-patterns. An anti-pattern is the evil twin of a good design pattern. A good design pattern is a reusable requirement, design, or implementation that solves hard problems in a standard way, which is well designed, well documented, easy to maintain, and easy to extend. An anti-pattern is a design pattern that may have seemed reasonable at some time but has spread into many different parts of the system or code and is now a nightmare to maintain or extend.
20% of the code, 80% of the problem
Anti-patterns are often the root cause of the 20% of a system that cause 80% of the problems.
Anti-patterns can show up in requirements, design, or code. In requirements, they are inconsistent or conflicting requirements written in different parts of the requirements specification. Each requirement seems reasonable on its own, but when they are combined they result in overly complex systems to try to resolve the conflicts.
In design, anti-patterns usually arise from copying a pattern that was required in a previous system, such as handling of strings in a PLC or copying files in a PC, but that is no longer needed and adds complexity and reduces performance. A typical anti-pattern involves handling of exceptions. Modern languages contain “catch” and “try” methods to simplify exception handling, but copied patterns from older systems will have deeply nested conditionals that are nearly impossible to debug or change. In addition to error handling, anti-patterns may also be related to security setup, complex data manipulation, and string data manipulation. Anti-patterns show up in code through poor programming techniques. These anti-patterns can be as simple as using single characters for variable names, because “that’s the way we did it in Fortran”; exceedingly long modules and functions, because “that’s the way we had to do it in Basic”; or byte-at-a-time interfaces, because “the old network only supported one-byte-at-a-time transfers.”
Familiarity, without review
Anti-patterns are really just a bad habit, in which patterns from previous projects are reused without review. They are not reviewed because everyone says, “that’s how we have always done it, so we don’t have to look at that part.”
Anti-patterns may not always be the sign of a poor programming or design techniques; often they are the choice of a bad algorithm. In an analysis of a system with over 1 million lines of code and hundreds of modules in one project, we found that a small percentage of modules were causing the majority of problems, even correcting for the size of the modules. We measured size in several ways: lines of code, number of statements, and number of variables per statement. In all cases the same modules came up as outside of the normal range. There was no relationship to the developer or to any specific part of the system. After analysis, we discovered that all the problems were related to poor algorithm choices. A poor algorithm, even programmed by a good programmer, still caused more problems that should be expected. If there was one bad reason for the anti-pattern, it was the lack of review of the algorithm, and the tradition of just using the same pattern in multiple places.
It is easy to identify the anti-patterns in your system. Ask the maintainers to identify the anti-pattern in the code, the 20% of the code that causes 80% of the problems. Ask the coders to identify the anti-pattern in the design, the 20% of the design that takes up 80% of the code. Ask the designers to identify the anti-pattern in the requirements, the 20% of the requirements that make up 80% of the design complexity. Anti-patterns are usually not visible by the team creating them, but they are visible to the next team in the system lifecycle; all you have to do is ask them.
Allocate to fix old code
Fixing anti-patterns can be difficult. Usually the cost to fix an anti-pattern after discovery must be weighed against any continual maintenance expenses or redesign expenses. If you expect to extend or fix the anti-pattern section more than a few times, it is usually more cost effective to redesign and re-implement. Unfortunately, this is a difficult decision to justify because the payment can be slow. Fortunately, removing anti-patterns does not have to be done all at once. A reasonable rule of thumb is to allocate 10%-20% of your maintenance budget to replacing anti-patterns with good design patterns. Over time you will find that your maintenance and support costs will stabilize or decrease as bad patterns are replaced with good ones.
Eliminating anti-patterns will give you a system that is easier to maintain and extend, but be sure to look for anti-patterns in all parts of your project, requirements, design, and code. Don’t let the bad habit of no reviews seed your system with future anti-pattern problems.
– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at firstname.lastname@example.org. Edited by Mark T. Hoske, content manager CFE Media, Control Engineering.