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 #16, and was written by Hunter.
As a student in high school, I struggled when writing papers. I had a lot to say, but the resulting jumble of thoughts and ideas was poorly presented and confusing to the reader. A ninth grade teacher hammered me for this, and ultimately taught me that no article or paper could be successful if it lacked a logical organization. He preached the concept of first creating an outline to assemble the main concepts in a meaningful and logical way, and THEN fleshing out the paragraphs. This is a lesson I never forgot, and as I got into automation, I realized this same approach is just as critical to any kind of software development.
Concept: This applies to any major undertaking (such as writing a paper, making a presentation, or designing complicated batch code). Take the time to lay out a design and get the underlying structure right before you begin. You will save yourself hours of wasted effort, and your work product will be much more cohesive.
Details: When faced with a major creative endeavor, most people want to jump in and get started so they can feel that they are making progress. They sit down and immediately start writing/painting/banging out lines of software code. This method can eventually work, but the path to success will be a circuitous one full of wrong turns and rework.
Save the team a lot of wasted effort, and take the time to work out a solid framework before starting on the details. This concept applies to any major project but is especially true for software development. If you first outline the major components and think through how the parts will interact, the resulting code will be much simpler and testing and start-up will go infinitely smoother. Resist the urge to just sit down and bang out code. Many a project team has failed to do this and has blown the entire labor budget trying to patch and cobble something together only to ultimately step back, toss all the work done to date, and effectively start all over.
Once the design is complete, document it in a manner that is clear and unambiguous to the project team. The form of the documentation will vary depending upon the project size and type, but regardless, the documentation should be easily read and understood and easily updated as the project progresses to completion. This same documentation can be used for testing and checkout purposes at the end of the project and provided to the customer for future reference.
Watch-Outs: Due to tight schedules, many project managers encourage “concurrent engineering,” in which multiple teams are working simultaneously rather than sequentially. Fight the urge to let the programmers “get started” while another group is working out the software design details. If the programmers are allowed to begin in advance with no direction, much of their work product will ultimately have to be reworked or simply abandoned. When multiple people or vendors are part of project, spend extra time defining the boundaries where these groups interface. This is a common failure area of large projects.
Exceptions: Concurrent engineering is possible if it is done correctly. One portion of the design can be completed and released for detailed software development while the other areas are being designed and outlined. Keeping everything straight can be difficult, but it can work if the team communicates well.
Insight: This same advice is invaluable for writing a paper or creating a presentation. A simple outline will help focus the paper and make for a much more understandable document/talk. Start with a high level outline to list the concepts and the order of presentation, then add details to each section. Once a detailed outline has been created, converting it to a paper or talk is relatively easy because each line in the outline becomes a sentence or two in the final product.
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.
Connect with Greg
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.
Connect with Hunter
