I had a project a little while back where the work was already 95% done before I ever got there. Problem was it was over budget, kept getting delayed, and the original team of developers no longer wanted to work on it. I was called in to provide an estimate to complete the work.
What I encountered will forever haunt me as one of the messiest programs I have ever faced. The hardware was a relatively straightforward conveyor system; a very repetitive series of components. The code was a collection of ladder routines, one for each individual conveyor, of which the logic was largely copy/pasted with tags renamed.
Doesn’t sound so bad yet, right? This is where the details of the remaining work become relevant. Each conveyor routine needed to be customized for it’s expected function, so each routine was a little different, and I had to figure out why the existing implementation failed in 1% of situations. About 100 conveyors, 100 routines, 50 rungs each of poorly constructed, repetitive, error-prone logic.
This is a common problem in industrial programming: maintainability. Unless you’re already familiar with the code, this can take hours to get a feel for and understand before you’re even ready to make changes. The limitations of organization and structure common in industrial programming make larger projects like this messy.
A similar issue present here related to maintainability is scalability. One of the planned upgrades for this project was to double the size of the system. Maybe triple. In the current implementation that means potentially 200 new routines. Sure, copy/paste will get you halfway, but then you have to edit every. single. tag. This code is not well suited to expansion.
Let’s summarize: The code in front of us doesn’t scale well and isn’t easily maintainable by the next programmer (you). And it doesn’t entirely work. However, there’s already months of labor from several people to get this far likely indicating a significant effort required for a complete rewrite.
So what do we do? Debugging and improving the current code maybe a little faster than redoing it. It’s not a guarantee given the scope of the changes but it’s likely. However, that still leaves us with a messy result that isn’t going to cooperate well with the future expansion.
There’s a useful quote from John Woods, an old school PC programmer, that’s very appropriate here (and in literally every situation where you find yourself writing code): “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
Everything as it is, we have an obligation to redo this. If the problems needed to go away overnight we might find ourselves in a different situation but this is going to require significant effort whatever we decide. Might as well do it right and leave things better for the next guy, psychopath or not.
We’ve considered a lot of different factors here to reach this decision. Another time, another place, we may find ourselves making different choices. The important thing is to be aware of the pros and cons of each option and be able to justify our actions.
I did end up keeping a lot of stuff that was better off unchanged. The hardware was hooked up well so the I/O was generally left alone. The safety program was functioning well enough and not so complicated that it was beyond understanding – no need to tinker. The logic to control auto vs. manual control was all fine. Even though I chose to redo the core conveyor control doesn’t mean we can’t find plenty of rungs worth keeping. Remember the old adage, “if it ain’t broke, don’t fix it.
For this specific situation, the decision to rewrite was ultimately very successful. I scrapped 3000 rungs of ladder and replaced them with about 500. Much cleaner, more maintainable, and, most importantly, it did everything it was supposed to. It took almost three weeks to redo everything but that includes most of the work for the future expansion as well. By changing just a couple of tags the whole system is immediately ready to double in size.
Personally, I feel that the flexibility upgrade is worth it almost every time. Your clients shouldn’t depend on you specifically when they need help simply because you’ve written unreadable code. Unless the effort is massively greater or the timeline unacceptable, most projects could stand to be redone at some point in their lives. You can only slap on so many patches before it’s time to do them over the right way.
About the Author
David is a driven problem solver with a background in PC application and web development. He thrives on challenging tasks and tight deadlines, generally preferring high-pressure projects and living out of a suitcase. When he’s not working 100 hour weeks he can usually be found in the gym or the local pool hall, almost certainly making new friends.
Great article. It does a amazing job at illustrating the common issues with programming other people’s code that isn’t intuitive to anyone who does not do this for a living. I’ve struggled to convey this exact messages to my bosses and anyone else judging where I put my effort or how much time it takes me to do a task.
Yea, you don’t know until you’re finished. Makes me think of this: https://www.breen-machine.com/title-engineer-also-see-wizard/