The phone till and the desktop till disagreed
The same register on two devices measured its own speed two different ways, and a comment in the code asserted something that was true of three screens out of nine. How a claim written in good faith stops being true without anybody editing it.
Our register runs on a counter screen and on a phone. Same product, two layouts, because a runner walking a food hall floor and a person standing at a till want different things in front of them.
Both report how long each of their screens took to load. One of them had been telling the truth for months and the other had not, and the difference was a sentence somebody wrote down when it was correct.
The comment
Above the phone timer was this, in effect: a phone screen is drawn straight from data already in hand, so the drawing is the loading. Written by someone who knew what they were doing, and true when they wrote it.
By the time anybody looked again, the phone register had nine screens. Six of them fetch: the kitchen board, past orders, money, notifications, a receipt and an unpaid order. They fetch using the same functions the desktop register waits for.
The desktop half collects whatever the screen fetches and reports once it has arrived. The phone half sent its number immediately after drawing. So the phone Money screen reported two milliseconds while a request was still in the air.
Two records of one thing
This is a recurring shape and it is worth naming, because it turns up in kitchens as much as in code. Two records of the same thing that disagree, where nobody notices because nobody ever puts them side by side.
A stock count in a spreadsheet and a stock count in a system. A prep time the kitchen quotes and a prep time the screen shows a guest. Takings on a till report and takings in a bank statement. Each is defensible on its own. The disagreement is only visible when someone lines them up.
Here the two halves of one register meant different things by the word loaded, and had done for as long as the phone had screens that fetch.
What it cost
Nothing, directly. No order was wrong, no money moved incorrectly, nothing a person could see was broken. What it cost was the ability to find out that the phone register was slow, on the surface where speed matters most — a person holding a phone in a queue, not sitting at a desk.
The proof was the same method as the office: run it at phone size in a real browser, delay every request by 400 milliseconds, and read what it reports. Past orders went from 3ms to 433ms. Money from 2ms to 435ms. The kitchen board from 3ms to 456ms. The menu screen, which draws from data already in hand and fetches nothing, reported two milliseconds both times — the control, unmoved.
Before the fix, every phone screen reported two or three milliseconds whether it fetched or not. The screen that did real network work and the screen that did none were indistinguishable. That is the whole finding in one line.
The lesson is about comments, not phones
The comment was not wrong when it was written. It stopped being true because the thing underneath it grew, and a comment has no way of noticing.
The same happens with an operating procedure taped to the wall of a kitchen. It was accurate the day it went up. Then the menu changed, a supplier changed, a piece of equipment got replaced, and nobody took the sheet down because nobody was wrong.
The defence is not writing better notes. It is having something that fails when the note stops matching — a check that reads the actual list of screens rather than a list somebody maintains by hand. Ours now does, keyed on which functions genuinely fetch, so adding a tenth screen that loads data fails until somebody deals with it.