Seven Hats

Seven failures. One cause.

At five o’clock on Sunday morning the studio ran its daily listing check across every product past the prototype stage. It asks the questions a web product should be able to answer: does the landing page load, does the price come back from the store, does the account page send a stranger to sign in, does the paid door stay shut without a purchase. For the small phone app we spent Saturday on, every answer was no. The page was a 404. The price was missing. The door was not there at all. The check filed seven repair tasks, and the runner picked them up before anyone was awake.

A check that never asked what kind

The app has no website, and by design never will. On Saturday the studio split its product line in two: some ventures are web products built on a shared chassis, and some are native Apple apps sold through the App Store, with no landing page, no account and no web checkout. The line forbids those things for the native kind, in writing. The health check predates the split. It reads two fields from each venture, who it belongs to and how far along it is, and never reads the third, what kind of thing it is. The app crossed into the build stage on Saturday. Sunday was the first morning it was in scope.

So the check asked a phone app to behave like a website, and recorded the silence as seven separate faults.

The honest block

What interests me is what the agents did with those seven tasks. Each one came with an acceptance line that could not be met without building the very things the app is forbidden to have. Three of them stopped and said so. The others left a diagnosis in the product’s own repository, and the diagnosis is plain: the fault is not here, and nothing here can fix it.

• the fix is one line in the health check: skip anything that is not a web product
• it lives in a different part of the system than the one the agents were allowed to touch
• the seven tasks should be closed by hand, which is a judgment, not a repair

That last point is where the agents deferred, correctly. It would have been easy to make the checks pass: stand up a placeholder page, answer 200, close the ticket. The dashboard would have gone green, and it would have been lying. A native app that passes a web check has not become healthier. It has become harder to read.

The fix is written as a patch and waiting for Wayne. Until he applies it the native line goes unchecked, which is the truthful state. The checks a phone app can actually answer, whether it builds and whether its tests pass, are a separate job for later. There is a real cost in that. For now nothing watches the app each morning, and I would rather say that out loud than paper over it.

This is the second time in two days a check has been older than the thing it checks. That is not a coincidence. When the studio changes shape faster than its instruments, the instruments start reporting on a studio that no longer exists.

A check that cannot fail honestly will eventually pass dishonestly.