The verification inversion

Barry Boehm published the spiral model in 1986, and it is worth studying precisely because it lost. Each turn of the spiral demanded objectives, then a risk analysis, then often a prototype built to answer a single question and afterwards thrown away, and only then implementation. The discipline was widely admired and narrowly practised. Teams could not justify building things they intended to delete, the risk analysis read as ceremony next to shipping, and lighter methods took the field for twenty years on the strength of that arithmetic.

The arithmetic no longer holds. A throwaway prototype is an afternoon at the outside and frequently twenty minutes, which means the one component of the spiral that still carries a real cost is the risk analysis it existed to serve. What was overhead became the work. The same inversion shows up in the ordinary shape of a day: the paragraph describing what you want is now longer-lived and more valuable than the four files a model writes from it, and the four files are close to disposable, which is a sentence that would have been absurd in any prior decade of the craft.

The other half of the arithmetic is the half that did not move. Boehm’s other well-known result is a curve, the cost of correcting a defect rising steeply the later it is caught, cheap in specification and punishing in production. The multipliers he reported have been contested ever since and we do not lean on them, but nobody has seriously disputed the shape. So one input collapsed toward zero while the consequence of getting it wrong stayed exactly where it was, and when one input to a process becomes free and the others do not, the process reorganizes around whatever is still scarce. What is still scarce is knowing whether the thing is right.

This is why the job description changed underneath people who never agreed to change jobs. The developer who spirals tightest now is not the one who produces most; producing is the commodity. It is the one whose specifications are precise enough that a generated implementation can be checked against them, who asks a separate session to attack a plan before any code exists, who reads the generated tests before the generated code because a test that asserts a truth about nothing will pass forever and cheerfully. None of these are new skills. They are old skills that used to be optional because the slowness of writing things by hand did much of the verification silently, one line at a time, as a side effect of the labor. The labor is gone and the side effect went with it.

The same logic runs outside software wherever a draft became free. The scarce contribution in a legal memo, a diagnostic summary, or a financial model is no longer the drafting, and everyone in those rooms has quietly been moved into the seat where the question is not can you produce this but can you stand behind it. That question was always the more interesting one. It has simply stopped being the part of the work anyone can afford to do last.