Fix the gauge before the engine

Time spent making a measurement honest always feels like time not spent making the product better. It produces no feature, no screen a customer sees, nothing to show anyone. It is the least satisfying work there is.

Here is the argument for doing it anyway, with a timestamp on it.

What happened

The phone register's load-time numbers were wrong — they measured the moment a screen finished drawing rather than the moment it had its data. Fixing that changed no behaviour and made nothing faster. It only meant six screens started reporting what they actually cost.

Within the hour, one of those numbers stood out. The notifications screen reported 834 milliseconds in a test where every request was slowed by a fixed 400. Every other screen reported a shade over 400.

Four hundred is one round trip. Eight hundred is two. The number said, without anybody reading a line of code, that this screen was going to the server twice when it should be going once.

It was

The screen asks for two things: orders still waiting to be paid, and recent orders so it can show refunds and voids. It asked for the first, waited for the answer, then asked for the second.

The second question does not depend on the first. They go to the same place. They could have been asked together and were not.

That matters more than it sounds. Our database lives in North America and the venues using this are in England, so every separate question costs a crossing and back. Two questions in a row is two crossings for a screen that needed one. For someone holding a phone behind a counter with a queue in front of them, that is the difference between a screen appearing and a screen arriving.

Asking both at once took four lines. The screen went from 844ms to 430ms in the same test, and landed exactly level with the past-orders screen next to it, which had always asked once.

Two controls, neither moved

The measurement is only worth anything because of what stayed still. Past orders read 437ms before and 438ms after. The menu screen, which fetches nothing, read 2ms both times. If the change had made everything look better, the harness would have been what changed, not the product.

This is worth copying whenever you measure anything in a venue. If you time a process before and after a change, time something you did not change as well. If both improve, you learned something about your stopwatch.

Nobody had reported it

That is the part that argues for the instrument. This screen had been making two trips for as long as it had existed. No operator complained, because it was never quite slow enough to be worth mentioning and nobody had a faster version to compare it to. It would have stayed that way indefinitely.

It surfaced the same hour the measurement became honest, and it surfaced as a number rather than as an opinion. Nobody had to be clever. The instrument said two trips and there were two trips.

The order of operations

So: if you are about to spend a fortnight making something faster, spend a day first finding out whether you can tell. Not whether you have numbers — everybody has numbers. Whether the numbers move when the thing they claim to measure moves, and stay still when it does not.

The honest version of this is that we did the fix first and the instrument second, over years, and only found out the numbers were wrong because one of them was implausibly good. Four milliseconds for a settings screen is what started it. A number too good to be true usually is not measuring what you think.