Separating good code from bad: The “paper-and-pencil” method

As the digital age continues to grow, the automation industry keeps up with upgrading or replacing control systems. When migrating, try the simple paper-and-pencil method to help identify programming issues.

By Jeff Monforton November 4, 2014

In society today, computer technology has become ever present. We use smartphones, tablets, laptops, the internet, web pages, and smart TVs. The digital age is certainly all around us. The automation world has also been moving in that direction for over 25 years.

It is for that reason that we’ve been moving in this direction for as long as we have, and that brings up the requirements of today. Our industry is seeing the obsolescence of those initial control systems and the need to upgrade and replace. As such, we are proceeding down upgrade paths to address this need.

Most of those existing control systems have been tinkered with and tweaked for years, all too a vary effect. There is a significant amount of truly valuable knowledge contained in those systems that needs to be captured and migrated. There is also a significant amount of really bad code as well as things that have simply been abandoned in place. As we go to migrate these systems, how do we separate the wheat from the chaff?

The typical approach by most of the technological generation is to take the existing application and start deleting, cutting, pasting, and readdressing. This does result in the current code being converted and the plant put back into operation. However, this also often results in adding to the incomprehensibility of the programming. This brings up the topic of discussion, the case for paper-and-pencil. This is somewhat of an antiquated approach but something worth considering.

The "paper-and-pencil" methodology is fairly simple:

1. Print out the program ("paper")
2. Review the program, annotating ("pencil") what is worthwhile and what its requirements are
3. Gather your notes and requirements together
4. Develop a clean, well-documented approach to the solution
5. Implement the solution.

The real key to this is the methodical approach to the solution during the review process. Instead of simply reworking things on an ad-hoc basis, patterns can be discerned and a more comprehensive approach applied. This allows interfaces to be cleaned up and documented, as well as code implemented in a more straightforward manner. Items up for deletion can be considered thoroughly before they are actually removed.

The end result of this level of review is a hard copy of thoughts, notes, questions, and actions that can be applied. This hard copy is also a historical record which can be of great import. How many times have we deleted something to only have to figure out what was deleted and why.

The implementation of paper-and-pencil is nothing magical, it will not stop you from making mistakes. What it does do is force you to slow down, consider things in depth, and consider the system as a whole before working up the new solution. Considering the system in total is important when upgrading using the same manufacturer, however, it’s critical when changing to a completely different manufacturer or platform.

There are great things that are coming from the digital age. There are enormous opportunities to improve systems and processes. There are also enormous opportunities to turn “mole hills into mountains” when it comes to mistakes. Sometimes the best technology for solving the problem was not invented yesterday.

This post was written by Jeff Monforton. Jeff is a senior engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.