Why OEMs Write Code the Way They Do

By Bryce Yokom, owner of Plantwide Integration. Published 2025-12-20. Originally posted on LinkedIn.

The breaking point

"Controls on Park 1."

That phrase haunted me as an automation manager. We were fielding so many support calls that we considered a dedicated hotline just to answer them. Something had to change.

I recently saw a video about aliasing from a technician's perspective, frustrated with indirect references and modular structures. I get it. But I think it's worth understanding why OEMs and integrators inevitably move toward modular design.

It's not to show how smart we are.

The reasons

1. Typos will kill you

Copy-paste errors are the most common bugs I see, in PLCs and HMIs alike. Tag names, IO addresses, fault text parameters. When you're on the shop floor, your limited time should be spent on machine function, not hunting typos.

Modular code eliminates entire categories of these errors. You write it once, test it once, and reuse it everywhere.

2. Plants don't have controls engineers

Most facilities don't have dedicated controls staff. They don't have remote access. They're overwhelmed by the number of platforms in their building and often don't have the right licenses to get online.

So you push information to the screen. You build faceplates that show everything maintenance needs without opening the code.

3. You can't scale engineers

There are a limited number of experienced controls engineers in any region. Even fewer who know your specific type: discrete, process, motion, safety. Companies with resources are competing for the same talent.

Selling 10 machines a year with 2-3 engineers? Manageable. 100 machines? 500? Good luck.

Eventually you hire out of desperation. That elegant functional style with the massive bit arrays, IO used directly in code, no Control Modules, no Equipment Modules, no faceplates. It becomes chaos.

So how do you scale without scaling engineers?

You build the DVD player.

AOIs are the DVD player. It's easier to teach someone to use a DVD player than to build one from scratch. Your senior engineers build the DVD players. They handle the complex logic. Your entry-level engineers press play. They configure inputs, set parameters, wire it into the sequence. They don't need to understand every line inside the AOI to use it correctly.

This lets 1-3 senior engineers write complex, reusable logic while 5-15 entry-level engineers assemble and configure it like building blocks. That code is tested, version-controlled, and reused at scale.

Some examples of these frameworks: PlantPAx for process, Machine Builder's Library for discrete. I'm not endorsing these, only making you aware they exist.

Yes, the first machine takes longer. Building a framework takes time. That's the tax you pay to make every future machine faster, safer, easier to program, tested, and easier to check out. That upfront investment pays for itself many times over.

This also keeps engineers engaged. They're solving new problems instead of fixing the same bugs repeatedly. You build a development path. You improve retention. You cut travel. Service teams can solve their own issues in the field.

4. Time to market

Machine building is cutthroat. If I can program 10x faster, commission 10x faster, and ship fewer bugs because I'm focused on machine function instead of hunting typos, I win.

If you're a "Replace All" programmer, you will ship copy-paste bugs. You'll chase broken HMI links. You'll spend time on things other than function. Other than safety.

5. Quality that builds on itself

Pulling code from your last shipped project fails at scale. Different engineers pulling from different projects, no version control, no change control. Everything lives in someone's head.

Modular programming gives your team structure. Continuous improvement. Change control. Even on custom machines, you're reusing tested, proven modules written by the right skill level for the complexity.

No more "change one thing, break three others." Your code is encapsulated. More time spent adding features and metadata. Context at the edge. Saving customers money as they start their digital transformation journey.

6. Support without nightmares

When everyone pulls from their last program instead of building from standards, service becomes impossible. Six different engineers, six different solutions to the same problem, zero consistency.

How can anyone except the original programmer troubleshoot that?

I don't want phone calls day and night. I want problems solved without pulling out my laptop. Better yet, solved before they even call. The HMI has everything they need. The program doesn't change. What changes? Sensors fail. Parameters drift. Materials vary. IO burns out.

Give customers the tools to solve their own problems.

7. Training and onboarding

Programs should be structured the way people think: building blocks assembled into something complex made simple.

The alternative? Spaghetti that only the original programmer can follow.

How do you train someone on that? How do you make an inexperienced engineer productive in weeks instead of years?

"But maintenance can't understand it!"

If maintenance is digging through your code, you've already failed them.

Maintenance shouldn't have to read code to fix problems. They should be able to understand machine behavior. That means clear state models, useful fault codes, cause and effect visibility, IO health at the HMI layer, and breadcrumbing on the HMI. Your job is to make them effective diagnosticians.

Every OEM's code is different. Maintenance can't be expected to learn the ins and outs of all of them. Your 300-rung routine isn't as intuitive as you think it is.

"Must be able to program from scratch"

When I see this on a job posting, I know they're not using modular programming. What I usually hear is: "We don't have standards."

Can modular code be done wrong?

Absolutely. It can be a mess. It can cause scan issues. It can use obscure strategies and features.

But so can functional programming. At least modular has a path for improvement.

And yes, bad modular code can be just as bad as bad functional code. AOIs nested four layers deep. Hidden tags. Looping JSRs. The discipline counts as much as the structure.

The cost of getting it wrong

At scale, bad code isn't just inconvenient. It's expensive. It drives warranty calls, burns service hours, and creates liability. Every "Controls on Park 1" call has a cost: your time, your customer's downtime, your reputation. And the code you're currently working on.

I've been on both sides

I started as a service technician. I remember the first time I opened a program full of AOIs and had no idea where to start. I remember watching my mentor present modular code in a tray former and feeling completely lost. Learning something new is uncomfortable. That doesn't make it wrong.

If you're constantly improving your craft, studying other people's code, deliberately practicing, always looking for a better way, you'll find your way to modular code.

If you don't, you'll still be doing it the way everyone did with PLC-5s and SLC-500s. Just with fancy tag names.

I want to make PLC programming better for everyone. That starts with understanding why the industry has moved this direction and educating programmers on how to do it well.