Manufacturing software development: Bigger is not always better

One of the many advantages of participating in professional organizations is the opportunity to learn about successful and unsuccessful automation programming projects. A recent project proved the old saying, "bigger is not always better." While bigger may be better for bank accounts and dessert servings, it is definitely not better when applied to programming, system designs, and control designs. More lines of code in a software program do not necessarily equate to better software. 

Fewer lines of code

The project involved fixing a custom report package that had been built by a company control engineer. The problem was that the engineer was not a programmer and had never received any formal training in software design, software engineering, or programming.

There were no established procedures for software development and no policies for design reviews. The result was a brute force approach, which used a separate function for each specific month and year and excessive code duplication. There was no documentation on the developed software. There were no comments in the code and no header descriptions on any of the functions. The report failed as soon as an unprogrammed date was reached, and no one remembered how the software was intended to work. A complete redesign and rewrite fixed the problem and reduced the number of lines of code from almost 10,000 lines to less than two hundred and eliminated more than 100 unnecessary functions in the process.

The lesson that should be learned from this example was that a better process was needed to develop software. No one would expect that giving a chemical or electrical engineer a 3D modeling tool would give him the skills needed to become an automotive designer and develop a new car design. However, too many managers and engineers think that giving chemical, electrical, or mechanical engineers a programming tool will make them qualified to develop professional software. There is more to effective software development than just a sophisticated programming package. Tools without training are just engineers’ toys. Using tools without effective policies and procedures are just hobbies.

A key point to remember is that the ineffective design and development of software is a people problem, not a technology problem. Improving technology allows us to build software faster, but that doesn’t necessarily mean better. Without training, knowledge of the underlying solution space, and some measure of experience, technology tools are often wasted. 

Four lessons of software development

The key lessons that should be learned in developing safe, supportable, and robust manufacturing software are: 1) provide focused training on new tools or provide the time to experiment and learn the environment before using it in a production solution; 2) develop comprehensive policies for the review of all software designs before they are committed to code; 3) write procedures on how to conduct design reviews; and 4) write effective procedures for how to conduct code reviews. The purpose of the design review procedures is to uncover ineffective algorithms, not to judge the designers. In his book Creativity, Inc. Ed Catmull, president of Pixar Animation, discusses the creative process and how it is iterative, and our first, second, and even later attempts are often in the wrong direction. An independent viewpoint often points out the flaws that we cannot see. The purpose of the code reviews is to identify best practice implementation weaknesses. Writers of code, just like writers of books, screenplays, and columns in trade magazines, need editors to review and correct mistakes that the authors cannot see.

The development of safe and reliable manufacturing software, and especially any control system software, requires that there is a high level of maturity in training, policies, procedures, and tools. When combined with good engineers, these provide the winning combination for building future successes.

Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl@brlconsulting.com. Edited by Chris Vavra, production editor, Control Engineering, CFE Media, cvavra@cfemedia.com.

MORE ADVICE

Key concepts

Establish procedures for software development and create policies for design reviews.

Ineffective software design is not a technology issue; it’s a people issue.

Mature policies and a strong training program are vital for developing safe and reliable manufacturing software.

Consider this

What best practices and training policies can companies use to cut down on potential software development mistakes?

ONLINE extra

See other Manufacturing IT articles and additional stories by Brandl linked below.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.