The following tip is from the ISA book by Greg McMillan and Hunter Vegas titled 101 Tips for a Successful Automation Career, inspired by the ISA Mentor Program. This is Tip #27, and was authored by Hunter.
Over the course of many projects, my project team and I have learned this tip the hard way, and with every project we promise to test new or revised software harder and more thoroughly than the time before. Despite all of our efforts, we STILL find small bugs late in the game that require us to touch each and every module to correct. I do not know if we will EVER learn this lesson completely, but we have gotten much more vigilant in our early testing. Pain has been very instructive.
Concept: 100 copies of garbage is a LOT of garbage!
Details: Many young engineers are in a hurry to show progress so they create a template, decide it works, and promptly make 100 copies to show their boss what they have accomplished. Later a bug (or two or three) is noticed, and suddenly they have two or three hundred bugs to fix rather than just two or three.
Earlier tips highlighted the fact that the automation field demands fanatical attention to detail, and this concept is a clear example. When creating a piece of code that will serve as a template for others, beat on it mercilessly to ensure the code is bug free. Once that is accomplished, give it to someone else and let THEM beat on it some more. Test it in every way possible, and make sure all of the problems have been wrung out before releasing it for replication. Doing this takes more labor initially, but it will save hours, days, and even weeks of labor further down the road.
This process seems like a simple task, but actually accomplishing it on a routine basis is always difficult to do. When the project is starting up and lots of activities are going on, finding the time and discipline to thoroughly debug code prior to replication can be challenging, but the consequences of NOT doing it can be dramatic.
This same concept applies to higher levels of programming. When programming a system with five virtually identical reactor trains, create and thoroughly test the software for one train in its entirety before replicating that software to the other four trains. If possible, create the first reactor train software, test it as thoroughly as possible, and then give it to the client for still further testing and review. Once everyone is satisfied with reactor train No. 1, THEN replicate the software for the other trains.
Watch-Outs: Have someone other than the original programmer test the code. As mentioned previously, a second person is much more likely to spot errors the programmer has overlooked.
Exceptions: None … unless the project is a time and material job and maximizing billable hours is the primary goal. (Just kidding!)
Insight: Once a piece of code HAS been tested and proven, consider moving a copy of it to a system library where others can use it. Doing this can save hundreds of hours of development work and reduce project risk.
Rule of Thumb: If a piece of code is to be replicated many times, always have two different people independently test it whenever possible.
About the Author
Gregory K. McMillan, CAP, is a retired Senior Fellow from Solutia/Monsanto where he worked in engineering technology on process control improvement. Greg was also an affiliate professor for Washington University in Saint Louis. Greg is an ISA Fellow and received the ISA Kermit Fischer Environmental Award for pH control in 1991, the Control magazine Engineer of the Year award for the process industry in 1994, was inducted into the Control magazine Process Automation Hall of Fame in 2001, was honored by InTech magazine in 2003 as one of the most influential innovators in automation, and received the ISA Life Achievement Award in 2010. Greg is the author of numerous books on process control, including Advances in Reactor Measurement and Control and Essentials of Modern Measurements and Final Elements in the Process Industry. Greg has been the monthly "Control Talk" columnist for Control magazine since 2002. Presently, Greg is a part time modeling and control consultant in Technology for Process Simulation for Emerson Automation Solutions specializing in the use of the virtual plant for exploring new opportunities. He spends most of his time writing, teaching and leading the ISA Mentor Program he founded in 2011.
Hunter Vegas, P.E., holds a B.S.E.E. degree from Tulane University and an M.B.A. from Wake Forest University. His job titles have included instrument engineer, production engineer, instrumentation group leader, principal automation engineer, and unit production manager. In 2001, he joined Avid Solutions, Inc., as an engineering manager and lead project engineer, where he works today. Hunter has executed nearly 2,000 instrumentation and control projects over his career, with budgets ranging from a few thousand to millions of dollars. He is proficient in field instrumentation sizing and selection, safety interlock design, electrical design, advanced control strategy, and numerous control system hardware and software platforms.