Control system programming: More design time, less implementation time

Engineering and IT Insight: Lazy?! Great control system programmers spend more time in design so they can spend far less time in the implementation stage. While this might seem that you need to be lazy to be a great control system programmer, you’re just being smart, efficient, and thrifty with programming time and budget.

By Dennis Brandl October 15, 2014

It takes more than just good programming habits to be a great control system programmer. There are multiple skills involved in developing robust, reliable, efficient, and elegant control systems. Being a great control system programmer requires skills in designing systems, implementing systems, debugging systems, documenting systems, and working with diverse teams. One important point to remember is that not everyone has equal skills or abilities in every field. Some people are better at designing systems but are mediocre, at best, in handing the details required for efficient programming. Some people are great at debugging systems but fail when documenting systems and implementations, while others are world-class coders but can’t work well with other team members. If you want to become a great control system programmer, it is important to recognize your strengths, determine where you need improvements, and systematically address your weaknesses.

One of the most common weaknesses that control system programmers have is system design and architecture. Many control system programmers are self-taught with degrees from other fields, and have had no formal software engineering training beyond a programming class. Even those with degrees in computer science often focused on software coding and not system design and architecture. However, there are good design habits you can develop to help in designing efficient and elegant systems, and robust and reliable architectures.

Be lazy: Reduce overall time spent

A best design habit is to "be lazy." This means trying to reduce the amount of code you must write, test, document, debug, and install by spending more time in the design phase and less time in the implementation phase. It is better to spend time developing an efficient design using 1,000 lines of code than a quickly written but poorly thought-out design using 10,000 lines of code that never seems to be completely debugged and is always being "upgraded."

The way to "be lazy" is to never, ever stop reading and learning about new architectures and new methods. Software development is not a well-defined and static environment; it is continually evolving. As computers get faster, memory gets cheaper, networks get faster, and disks get faster and cheaper, designs and models that were previously unreasonable are now possible. Architectures that were unimaginable even five years ago are now becoming mainstream solutions. The best way to learn about new design patterns and simpler methods to address problems is to get into the habit of reading software magazines and blogs. Join the IEEE Computer Society and read the monthly magazines. Plan to spend at least 30 minutes per day reading about different ways that others are designing solutions. These 30 minutes will also to keep you current with new tools so that you can creatively apply newly discovered solutions to new problems.

In addition to "being lazy," there are very specific design habits you can learn. Start by designing your interfaces first, then the algorithms. When you design your interfaces first, you are approaching the problem from the viewpoint of the user of your code. You should design an interface so that it is easy to use and doesn’t require knowledge about the implementation algorithms. If your interface takes the smallest "mental" space to understand, then it will also be easy to debug and document. 

Be lazy: Reuse code

Develop the habit of reusing designs, the ultimate method of "being lazy." Do not be afraid to cut and paste design elements from previous projects. Develop and use a library of reusable designs, and share that library with fellow designers. One bad design habit to avoid in reuse is overgeneralization. You can design for reuse, but if you go too far in generalizing a design element, you risk making the interface much more complex. This is a common problem when designing standard solutions, where every low probability use case must be addressed. When developing a design, consider the possibility of reuse of the design, but don’t try to design it to handle 100% of the situations. Instead shoot for 50% to 75% coverage.

Be lazy: Document for faster validation

Develop the habit of designing in a formal representation. Learn UML, the Unified Modeling Language (Welcome To UML Web Site!), to document your designs so that they can be easily understood and validated. Natural languages, especially English, are terrible at documenting designs. It is too easy to miss important elements and inconstancies using an unstructured natural language. UML performs the same role in software engineering as circuit diagrams do in electrical engineering. No electrical engineer would just start wiring together components without a circuit diagram, and no software engineer should just start coding without a UML definition.

The good design habits you develop will make you a better control system programmer by reducing the amount of control system programming you need to do. With well-thought-out designs that reuse elements, are formally documented, and are based on state-of-the-art architectures and models, your control systems will be more robust, reliable, and maintainable.

– 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, mhoske@cfemedia.com.

ONLINE extra

Welcome To UML Web Site! 

This posted version contains more information than the print / digital edition issue of Control Engineering.

At Home, search Brandl for more on related topics.

See other articles for 2014 at Home.

See other Manufacturing IT articles

See related story on understanding UML.