Design patterns and anti-patterns

IT and Engineering Insight: Good software design solves hard problems in a standard way and is well documented and easy to maintain and extend, as opposed to code that seemed reasonable at some time but has spread and become a nightmare to maintain or extend.

09/26/2012


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 dbrandl@brlconsulting.com. Edited by Mark T. Hoske, content manager CFE Media, Control Engineering.

www.controleng.com/it 



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
Control Engineering Leaders Under 40 identifies and gives recognition to young engineers who...
Learn more about methods used to ensure that the integration between the safety system and the process control...
Adding industrial toughness and reliability to Ethernet eGuide
Technological advances like multiple-in-multiple-out (MIMO) transmitting and receiving
Virtualization advice: 4 ways splitting servers can help manufacturing; Efficient motion controls; Fill the brain drain; Learn from the HART Plant of the Year
Two sides to process safety: Combining human and technical factors in your program; Preparing HMI graphics for migrations; Mechatronics and safety; Engineers' Choice Awards
Detecting security breaches: Forensic invenstigations depend on knowing your networks inside and out; Wireless workers; Opening robotic control; Product exclusive: Robust encoders
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
News and comments from Control Engineering process industries editor, Peter Welander.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
Anthony Baker is a fictitious aggregation of experts from Callisto Integration, providing manufacturing consulting and systems integration.
Integrator Guide

Integrator Guide

Search the online Automation Integrator Guide
 

Create New Listing

Visit the System Integrators page to view past winners of Control Engineering's System Integrator of the Year Award and learn how to enter the competition. You will also find more information on system integrators and Control System Integrators Association.

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.