An Approach to Building Production Tools

I was on a business trip for a week the other day.

We had a pilot mass-production run for a product I am working on, and I was helping on the manufacturing floor. While I was there, I had some thoughts about the production tools used on site, so I wanted to write them down.

What I mean by a production tool

By "production tool," I mean software used for tasks such as calibration and adjustment before shipment. For example, one of the products I am responsible for measures a target object and acquires detailed data from it. Even if you measure the same target with multiple products assembled from the same parts, the measured data still varies.

Suppose you measure a calibrated target that is guaranteed to produce a certain value. If several units should all display 100 but instead display 99, 98, and 102, that variation is unavoidable because each piece of hardware has individual differences.

So how do you absorb that difference? You apply an offset in software. In the example above, the displayed values 99, 98, and 102 differ from the true value 100 by -1, -2, and +2. You measure those deviations in advance and add the necessary correction when showing the value to the user. That way the user sees the correct measurement.

There were many steps like this in the current product's production flow. People on the manufacturing floor, including non-technical operators, use software to perform those tasks.

The problem is that our current software was clearly built for software engineers. For example, it can describe command-level operations sent from the tool to the instrument for communication. It can do almost anything, but from the point of view of someone on the floor, it is very hard to understand what they are supposed to do.

An idea for solving it

For people on the floor, the ideal tool is probably something with very few buttons, where a single button finishes the task. One of the operators literally told me, "There are too many buttons, so I do not know what I am supposed to do." But from the point of view of a software engineer, that can be inconvenient when debugging or when you need fine-grained control.

While I was on the trip, I kept thinking about how to design software for these conflicting needs. The approach that came to mind, which is admittedly common, was to provide both a simple mode and an advanced mode.

You see this kind of approach in antivirus software and elsewhere. It seems capable of satisfying both sets of requirements. It is a common pattern, but personally it had been a blind spot for me.