Elegance Is Overrated When the Plant Is on Fire

Introduction

Technical professionals are not always known for keeping things simple, and sometimes that lack of simplicity comes at a high cost. What appears to be elegant code can easily turn into a troubleshooting nightmare. What seems efficient to one person might cause serious issues during a late-night emergency. Often, the more technically skilled someone is, the more likely they are to create overly complex code that is difficult for others to follow. While clever programming may be useful in software development, it is not always the best fit for a plant floor.

Understanding the Audience

In school, programmers are often rewarded for writing short and efficient code. While efficiency has its benefits, control specialists must consider who will be working with or troubleshooting the code in the future. That person may be a coworker on a night shift or a maintenance technician trying to diagnose why a motor will not start. If someone with basic system knowledge cannot quickly understand what causes a specific output to fire—especially during a plant shutdown—then the code should be rewritten for clarity.

Real-World Pain: A Migration Mistake

Our control specialists experienced the impact of overly complicated logic during a system upgrade. The team migrated programming from a PLC-5 to a DeltaV DCS. Instead of redesigning the code and creating a clear narrative, the logic was copied line for line and translated into function block programming. This approach was like translating a story word for word without keeping the original meaning.

Had a clear explanation of the system’s functionality been created first, the new code could have been developed more cleanly and simply. Instead, each line of the old logic was placed into separate calculation blocks, which referenced each other in confusing ways.

The logic affected both environmental compliance and safety. When it became clear the system was not working properly, a lengthy investigation began. The resulting flowchart filled most of the office wall. Others had also attempted to untangle the logic over the past two years because of recurring issues.

The root cause turned out to be scan rate delays. The DeltaV system scanned once per second and had to communicate with a PLC on the other side of the plant. When both systems were PLCs, timing was aligned. With the slower DCS, delays caused the logic to run incorrect scenarios. While this issue might still have occurred with simple code, it would have been much easier to identify and fix.

Lessons Learned

This experience offered several lessons. The first was the value of simplicity in control logic. Keeping code simple does not always mean writing fewer lines. It often means using clear Boolean expressions instead of condensing everything into a single complex calculation.

Another lesson was the importance of proper code rewriting. During system migrations, teams should avoid direct code conversions. Instead, they should partner with professionals who can evaluate the old code and rewrite it to work effectively within the new system’s framework.

Conclusion

Code that seems impressive in development can cause major problems in live plant operations. Industrial control logic is not static. It is updated, reviewed, and adjusted over time by many different people. Because of this, clear and maintainable code is critical. While straightforward logic may not be flashy, it can prevent downtime and help keep operations running safely and smoothly.