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 Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant 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.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.