If it ain’t broke, don’t fix it.
That’s an old rule in industrial automation that has probably prevented as many problems as it has created:
I respect that rule.
If a machine has been running production reliably for five years, opening the PLC program and reorganizing code simply because we don’t like how the original programmer wrote it may not be a very good idea.
Working production equipment is not the place to practice software elegance.
But there is another side to this.
PLC programs age just like the machines they control. Changes get added. Components get replaced. Customers request new features. Someone adds a temporary fix during startup that becomes permanent. Another programmer makes a change three years later. Then another.
Eventually, the program still works—but understanding why it works becomes increasingly difficult.
That raises an interesting question:
When does PLC code become worth refactoring?
Working Code and Maintainable Code Are Not the Same Thing
A PLC program can control a machine perfectly and still be difficult to maintain.
Anyone who has worked on older equipment has probably encountered some version of this.
You open the program and find logic that has grown organically over years. Similar functions are programmed three different ways. Tags that made perfect sense to the original programmer no longer mean much to anyone else. Old logic has been bypassed rather than removed because nobody is completely certain whether it is still needed.
There may even be comments explaining changes made by someone who left the company ten years ago.
And, of course, the machine is running.
That last part matters.
Cleaning up industrial software is very different from refactoring an ordinary software application. A mistake doesn’t just crash a program. It can stop production or change how a physical machine behaves.
So I don’t believe we should refactor PLC programs simply because we can make the code prettier.
There should be a reason.
Look for the Right Opportunity
A planned machine shutdown can provide one.
So can a controls upgrade, obsolete hardware replacement, major process change, or significant machine modification.
If engineering work is already going to require testing and recommissioning portions of the machine, that may be the right time to address some of the technical debt that has accumulated in the automation.
That doesn’t necessarily mean rewriting the entire PLC program.
In fact, I would usually be suspicious of that approach.
Instead, look for specific areas where improving the structure provides a practical maintenance benefit.
Could three slightly different axis-control routines become one standardized structure?
Could machine states be made clearer?
Could repeated logic become a reusable function?
Could poorly named tags be replaced with names that actually describe what they represent?
Could alarms provide useful troubleshooting information instead of simply reporting “Machine Fault 37”?
Could obsolete logic finally be documented and removed?
Those changes have a purpose beyond making the programmer feel better about the code.
They make the machine easier to understand.
Standardization Is Where Refactoring Can Really Pay Off
One of the biggest opportunities during refactoring is standardization.
If every axis, valve, station, or device is programmed differently, troubleshooting requires understanding each implementation individually.
Standard structures change that.
Once a technician understands how one axis is handled, the next axis should look familiar. The same should be true for alarms, permissives, machine states, diagnostics, and common devices.
That doesn’t mean every machine needs to use an enormous software framework.
Sometimes simple and consistent is better.
The objective is not to build the most sophisticated PLC architecture possible.
The objective is to make the machine easier for the next person to understand.
And someday, you may be the next person.
I have certainly opened programs years after writing them and wondered what the original programmer was thinking—only to remember that the original programmer was me.
The Schedule Is Usually the Real Problem
Most controls programmers already know where their programs could be improved.
The problem is rarely knowing what should be cleaned up.
It is finding the time to do it.
During machine development, the priority is getting the machine working. Then comes debugging. Then customer acceptance. Then production.
Once everything works, nobody is particularly interested in hearing:
“I’d like another week to reorganize the PLC program.”
The next project is already waiting.
So technical debt accumulates.
That doesn’t necessarily mean the original programming was poor. Sometimes it simply reflects the reality of building production machinery.
The important thing is recognizing when an opportunity finally exists to address some of it.
There Is Another Reason to Start Thinking About This
Better structured automation may become increasingly important as AI-assisted troubleshooting and maintenance develop.
AI won’t magically understand a poorly structured machine.
If the PLC contains cryptic tags, inconsistent states, generic alarms, undocumented changes, and little useful event history, an AI maintenance tool faces many of the same problems a technician does.
Someone—or something—first has to figure out what all that information means.
Compare that with a machine that has descriptive tag names, standardized equipment structures, meaningful alarms, documented machine states, revision histories, and useful event records.
That information is valuable to technicians today.
It could also become the foundation for much better AI-assisted diagnostics tomorrow.
Don’t Refactor Just Because You Can
I still believe “If it ain’t broke, don’t fix it” is good advice.
A production machine isn’t a software-development experiment.
But that doesn’t mean we should ignore growing automation technical debt forever.
When a machine is already scheduled for an upgrade, major modification, or significant controls work, ask one additional question:
Is there anything in the existing software that we should make easier to maintain while we have the opportunity?
You don’t necessarily need a rewrite.
Sometimes a few carefully selected improvements in structure, naming, alarms, diagnostics, and standardization can make the machine considerably easier to support for the next ten years.
And that brings us to another subject worth discussing:
How much should we standardize our machine software in the first place?
That will be the subject of the next MWL Automation Note.
Manufacturing With Light (MWL)
MWL covers practical issues in laser materials processing, automation, motion control, additive manufacturing, machine design, safety, and advanced manufacturing—with an emphasis on what actually matters when technology reaches the shop floor.