Reduce Development Time and Project Risk by Testing and Proving New Code

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.

101 Tips for a Successful Automation CareerOver 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.

Hunter Vegas

About the Author
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. Vegas 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.
Print Friendly, PDF & Email

, , , , ,