Control system programming requires collaboration
Programming is often viewed as a lonely exercise, with programmers working alone with a large supply of caffeinated sodas and high-sugar snack foods. The truth is that programming and the other associated tasks of design, installation, debugging, and maintenance all require significant interactions with other team members, end users, and management. In kindergarten this is defined as "works well with others," and it is an important habit to remember in control system programming.
One of the most important ways to work well with others is to develop a buddy system. Writers have editors to correct their grammatical errors, actors have coaches and directors to improve their acting skills, athletes have trainers and coaches to improve their performance, and control system programmers also need buddies to review their work. Multiple studies have shown that one of the most effective ways to reduce errors in design and coding is a buddy system to perform reviews before any work is submitted. Researchers were shocked to discover that the simple habit of explaining the design and code to someone else, even if that person didn’t understand the details, eliminated up to 80% of design and code errors. By explaining the designs and code, the programmer is forced to look at them differently than when designing and writing alone. Hidden assumptions are made apparent because the programmer is forced to explain why something was done, not just how it was done. To become a better designer and coder, develop a buddy system with one or a group of other designers and coders. Having a buddy or two will not eliminate all errors, but it will significantly reduce the error rate in the program.
Another habit of great programmers and designers is to use version control and a source code control system (SCCS) for every artifact developed and used during unit design and code. An SCCS should always be used on every project for all final and shared code. It allows users to check-out and check-in code, documents, diagrams, and all other design artifacts. Great programmers and designers also use the SCCS for preliminary work before it is approved or needs to be shared, commonly called the unit development and unit testing phases. The primary reason for using an SCCS in unit design is that it allows designers and coders to experiment with different code structures and different designs. If the different work is not correct, the SCCS provides the ability to roll back to a previous design or previous code. Also, an SCCS usually provides a method to show the differences between versions, which is very useful to have when code buddies review the work. Check-in the work at the end of every day or whenever a significant change is made. If something goes wrong, a difference report will immediately point to the differences.
Not done until after cleanup
Working well with others also means cleaning up. Most developers will create "scaffolding" for construction and testing of code. Similar to scaffolding in building construction, it supports the code until it can be integrated with the rest of the system. The scaffolding also should be maintained in the SCCS, but the hooks to the production code should be removed before final unit testing and integration. Some of the more difficult problems to find are a result of test and scaffolding code left in the production system and having it triggered by unexpected interactions with other parts of the system. Just as in kindergarten, remember to clean up. The job isn’t finished until cleanup is done.
A final good habit in working well with others is to crank up all of the error messages and diagnostics available on the tools being used. The compilers, code checkers, and design checkers are trying to tell the programmer something, and the programmer needs to listen. It is far better for the programmer to find simple problems rather than having the code buddies discover them in reviews, or worse, the end users discover them during operation.
One final point—taught in every design and code book but often forgotten—is that the programmer cannot debug the way to correctness. If you spend more time debugging a unit than you spent designing or coding it, then stop. Review the design with the coding buddies. If the design is correct, then become a Sherlock Holmes when debugging. Try to determine how an error condition would be created. This focuses on the areas where the problem could be, rather than trying to debug a whole program. Buddies can serve as Dr. Watson, explaining what is impossible, and whatever remains, however unlikely, must be the source of the error. It may be surprising how often coding buddies will notice minor errors, such as uninitialized variables or using the wrong variable, that the programmer cannot see because the programmer "knows what is supposed to be there."
Great programmers and designers don’t work alone; they use friends and fellow workers to form a buddy system. They use their programming buddies to review their work, even their unit designs and code, because the simple act of explaining their decisions to their buddies reveals a large fraction of the errors. Great programmers and designers make life easier for their buddies by using source code control and version control to know what is changed and what needs reviews, and they clean up their test and scaffolding code to reduce the opportunities for error when their code and designs are integrated with their buddies’ code and designs. Working well with others is not just a kindergarten test, but a habit to adopt to become a great programmer.
– Dennis Brandl is president of BR&L Consulting in Cary, N.C. His firm focuses on manufacturing IT. Edited by Mark T. Hoske, content manager, Control Engineering, email@example.com.
This posted version contains more information than the print/digital edition issue of Control Engineering.
At www.controleng.com, search Brandl for more on related topics.
Or see the article linked below.
See other Manufacturing IT articles.