Skip to main content

°FAI: The Bug That Was Faking Our Numbers

Our press operators log every job on a tablet, order number, screens, setup time, run time, delays. That data flows into the weekly report the shop owner reads every Monday morning. The tablet form has been live about three weeks. The operators came back with a list and The Bug That Was Faking Our Numbers.

What the operators flagged

Most of the fixes were small. Stage timers that wouldn’t let you start one part of a job before finishing another, even though real shifts don’t go in order. Autosave that Android kept wiping every time it killed the tab in the background, so operators lost entries they’d already typed without realizing it. Two delay categories “Helped another operator” and “Touch-ups” that didn’t have buttons, so operators typed them in as notes that then disappeared from the reports. Order numbers short enough to break the system that matches jobs to screens in the dark room. We fixed all of them.

The bug that was lying to us

One was bigger. Tapping “Delay Over” should have stopped the delay timer and cleared the selected reason. It stopped the timer. It did not clear the selection. So the next time an operator tapped any delay button, the timer silently restarted and counted against the new reason. Nobody saw it happen. The reports just showed inflated delay numbers against random categories. We only caught it because an operator said her week’s delay total didn’t match her sense of the week. Ten-line fix, but every report the system had produced for weeks ran a little wrong.

Rebuilding the report

We rebuilt the weekly report itself. It used to show this week’s numbers in isolation, which made them hard to read, is 35 minutes of setup time good or bad? Now every section compares this week to last week with trend arrows, and shows year-to-date totals so a bad week reads against the bigger picture. We added new efficiency numbers too: pieces per hour by operator, average job length by screen count, daily throughput. All of it comes from data we were already logging.

What this really shows: every fix here came from operators using the form, not from anyone planning. The cost of changing the system is low enough now that we can actually act on what they tell us. That’s the whole point.

Tools used:

  • Claude (Opus 4.7 — bug diagnosis and code rewrites)
  • Google Sheets + Apps Script (data and report generation)
  • Tablet-based production logging system (the form on the shop floor)

Comments

Leave a comment