What running Krones lines taught me about writing operations software
I have an unusual job description: I am the sole developer of the MES/ERP platform at a Dubai beverage plant, and I also work shifts on the Krones production lines that platform reports on - blow molding, filling, inspection, packaging, palletizing. Most enterprise software is written by people who have never operated the process they are digitising. I get to be both the developer and the user the developer usually never meets. These are the lessons that crossed over.
1. Design for the 6 a.m. handover
Operations software is not read by a rested person at a desk. It is read by a night-shift operator handing over to the morning shift, by a supervisor with three problems running in parallel, on a shared terminal near a machine. That audience changes the design brief completely: one screen per question, big numbers before small explanations, and state that survives an interruption - because every task on a factory floor gets interrupted. Half of what looks like "clean minimal design" in my dashboards is really just respect for how tired the reader is.
2. Paper survives because it never crashes
Engineers laugh at paper logs, but paper has a spectacular feature set: it boots instantly, never loses a session, works during a network outage, and accepts any input format. A digital form does not replace paper by being digital; it replaces paper by being at least as fast to fill in and then doing something paper cannot do - totalling itself, flagging the out-of-range value, landing in the report without being retyped. Every form in the platform had to win that comparison honestly, or the floor would quietly go back to the clipboard. They are the harshest UX reviewers I have ever shipped for.
3. Only ask for what the operator will actually enter
Every extra field is a tax collected on every unit, every shift, forever. Ask for twelve fields and you get nine filled with garbage; ask for four that matter and you get four you can trust. The discipline is brutal prioritisation: capture what drives a decision (quantities, downtime reason, batch identity) and derive or default everything else. Data quality is a UX outcome, not a training problem - no memo ever fixed a form that was too long.
4. The report is the product
Nobody on the management floor logs into a dashboard at 7 a.m. What they open is the PDF in their inbox. For months I thought of the reports as the boring output layer of the real system; the factory taught me it is the opposite. The database, the APIs, the admin panels - all of it exists so that a correct, consistent, signed-off document arrives on time. Once I accepted that, effort moved to where it pays: report layouts the GM can scan in thirty seconds, numbers that reconcile across departments, and a generation pipeline reliable enough that "the report did not arrive" is never the morning's first conversation.
5. Build around OEM automation, not into it
The Krones machines are superb and entirely closed - the PLC layer is the OEM's domain, warranty-locked, and not something a plant developer should be poking. The leverage is in the layer above: the OEE tracking, downtime records, QC workflows, batch traceability and management reporting that wrap around the machines. Knowing precisely where that boundary sits - what the equipment will give you and what it never will - is, in my experience, the most underrated skill in industrial software. It is the difference between an integration plan and a fantasy.
6. Measure honestly or do not bother
The platform cut production reporting time by roughly sixty percent - and I will only ever say "roughly", because the before-state was distributed across spreadsheets, paper and people's evenings, and nobody was timing it with a stopwatch. The factory floor has a finely tuned detector for inflated numbers; the fastest way to lose the room is to claim precision you do not have. The same habit carries into my engineering write-ups: benchmark figures get their caveats attached ( same-runner, relative, virtualized hardware), and estimates get called estimates.
The throughline
Operations software succeeds on trust, and trust is built out of small mechanical things: forms faster than paper, numbers that reconcile, reports that arrive, claims that survive scrutiny. The factory floor taught me those before any codebase did - which is why I think running the lines made me a better backend developer, not a distracted one.