What Eight Years on the Shop Floor Taught Me About Building Manufacturing Software
Balaji Arumugam
Software Engineer
Contentsexpand_more
Before I wrote my first production React component, I spent eight years on the manufacturing floor at Tata International — implementing QMS systems, running Six Sigma projects, managing ISO 9001 and IATF 16949 audit cycles, and watching how production software either supported or fought against the people using it. When I transitioned to software engineering, I brought that experience with me. It changed everything about the software I build and how I think about building it.
The Gap Between MES Vendors and the Shop Floor
Most manufacturing execution software is built by engineers who have never stood at a machine, never filled out a shift handover sheet, and never needed to make a quality call under production pressure. The result is software that models a manufacturing operation the way a consultant's slide deck does — cleanly, abstractly, and wrongly. Calibration workflows that don't account for the three-minute window an operator actually has. Quality inspection screens that require 12 taps to record a single measurement. When I built the Machine Line module for the Amway India MES, the first thing I did was spend time on the floor before opening a code editor. The modules that came out of that — the behavioral safety workflows, the calibration scheduling, the quality inspection forms — looked different from what I would have built from a requirements document alone.
What QMS Thinking Looks Like in Software
A Quality Management System, at its core, is a documented set of processes designed to ensure consistent outputs and provide a traceable record when something goes wrong. ISO 9001 doesn't care whether your process is manufacturing a bearing or deploying a web application — the principles apply equally. In software, this translates to things most engineers already know but don't always practice: documented processes for how code moves from development to production, audit-trail logging on state transitions, and systematic non-conformance tracking when bugs reach users. When I built the Six Sigma digitization platform for Granules India, the DMAIC workflow wasn't a feature request I was implementing from the outside — it was a process I understood from running Green Belt projects. That made the difference between a system that technically covered the methodology and one that reflected how practitioners actually think.
Applying DMAIC to Feature Development and Debugging
Six Sigma's DMAIC (Define, Measure, Analyze, Improve, Control) is a structured problem-solving sequence developed for manufacturing defects. It translates surprisingly well to software debugging and feature scoping. Define: write down exactly what problem you're solving, not the solution you have in mind. Measure: capture the current behavior with data, not intuition. Analyze: find the root cause — not the symptom. Improve: implement the smallest change that addresses the root cause. Control: write a test that would have caught this regression. The discipline of not skipping to Improve before completing Analyze is the same whether you're chasing a process capability issue on a production line or a mysterious state bug in a React component.
Kaizen as an Engineering Culture
Kaizen — the Japanese philosophy of continuous incremental improvement — gets applied to software teams mostly as a buzzword in retrospective agendas. On a real manufacturing floor, Kaizen is ruthlessly concrete: a specific problem, a specific improvement, a specific measure of before and after. When I built the Kaizen module for the Continuous Improvement System at Granules India, I modeled it exactly this way — every idea submission required a problem statement, a proposed change, and a success metric. The same discipline applied to engineering culture means retros that produce one actionable change, not a list of grievances. Code review comments that identify a specific improvement, not vague style preferences. Small, measurable, compounding.
Building Software You'd Actually Trust on the Line
The test I apply to any manufacturing software I build is simple: would I trust this in a high-stakes production environment? That standard changes what you prioritize. Offline behavior matters because shop floors have connectivity dead zones. Error messages have to be actionable because operators can't call a developer at 2am. Access control has to be granular because a line operator and a quality manager are making different decisions with the same data. These aren't academic architecture concerns — they're requirements I've lived on the other side of. The software that earns trust on the production floor is software that behaves predictably under the exact conditions where you need it most.
- QMS Principles in Software: Documented processes, audit trails, and non-conformance tracking apply equally to software systems as to manufacturing quality.
- DMAIC as a Debugging Framework: Define the problem precisely, measure current behavior, find the root cause — before touching the code.
- Floor-first Design: Spending time on the production floor before writing a requirements document produces software operators actually trust.
Key Takeaway
Domain expertise isn't a soft skill — it's a force multiplier on every technical decision. Understanding why a process exists, what failure looks like, and what's actually at stake when the system goes down produces fundamentally different software than building from requirements alone.
“The best MES software isn't built from requirements documents — it's built by people who've felt the friction the software is supposed to eliminate.”