Five red rows and one job
The first morning anyone used a release, five screens went red on the speed board. Four had a reason already written down. One was a fix.
Nobody opens a back office at three in the morning, so for a day after each release our speed board shows nothing: no screen has been loaded on the new code, so no screen has a number. This morning somebody came in, opened the office and the till, and by half past six the board had five screens over budget on the deployed release. The rule we run says: take the worst one and make it faster.
We took one, and it was not the worst. Here is the order of reading that got us there.
Read the reasons before the numbers
The worst row was the till's first screen, six loads averaging 1.3 seconds. All six were first loads, which means the number is the download of the app itself, not the screen. Slimming that download is a real job, it is a large one, and it is one the owner has to choose to spend on. It has a line in our notes saying exactly that. Not this morning's job.
The dashboard was next, four first loads out of six, and its one route has already been through this exercise twice: every read it makes runs in a single batch, with nothing after it. Re-deriving that would have cost the morning and found what was found before.
The hub's route is one round trip deep, measured, and has had five passes. The till's notifications screen already fires its two reads together; what is left in its server time is a column we learned a fortnight ago measures how many requests a page fired at once, not how slow the way in is. Both have notes saying so, with the measurement attached.
The one that was a job
The permissions screen. One API call, warm, with about 285 milliseconds inside the route, which at our round-trip time to the database is three trips. Read the route and there were exactly three, in series, and the third was the first one repeated: a helper that checks whether you may edit fetched the list of classes again, moments after the route had read the same list for the screen. Three waits became one. The test that counts the trips was written first, failed with the number three in its message, and went green on the fix.
What this is really about
An alert board that lights up five things at once is not asking you to fix five things. It is asking you to read five things, and most of what you read will be a reason you already know. The discipline is writing the reason down the first time, next to the number, so that the next red morning costs ten minutes of reading instead of a day of rediscovery.
Four rows, four reasons on file, one fix. That is a good morning.