Build in order to learn

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.

— The Mythical Man-Month, F.P. Brooks (1975)

Half a century later this sentence still describes, with uncomfortable precision, what happens in most digital product projects. And the interesting part is not that Brooks was right. It is that the industry has systematically, and with remarkable persistence, chosen the second of the two options he lays out: deliver the draft as though it were the product.

The first system is the one that explains the problem to you

Brooks's claim has a curious structure. He does not say the first system is bad through lack of craft, or haste, or lack of resources. He says it is inevitable. And the reason is epistemological before it is technical: the first system you build on a new problem is the instrument with which you find out what that problem was. When you finish, you know things you could not have known at the start, and precisely because of that, what you built is obsolete relative to what you now understand.

Peter Naur put it from another angle a few years later: programming does not consist of producing a text, it consists of building a theory about a domain. The code is the trace of that theory, not the theory itself. From which follows something anyone who has inherited a system knows from experience: you can read all the code and still not understand the system, because what is missing is written nowhere. And from which also follows what matters here: if building is theorising, building is the activity where learning happens, not the activity that comes after learning.

This collides head-on with how work is usually organised. In most companies, building is the phase where what was already decided gets executed. Analysis comes before, validation comes after, and in between sits a stretch managed as production: someone handed over a baton, someone picks it up, and the success metric is fidelity to what was agreed. With that arrangement, everything learned while building is noise. Worse: it is a threat, because it questions the agreement that legitimises the work.

Learning is not the same as iterating

This is worth distinguishing from the more worn-out rhetoric of the craft. "Iterate" has become a word that can mean anything, including its most frequent meaning: repeating the same delivery cycle with the same degree of ignorance, only in shorter stretches. A team can run twenty iterations without having learned anything, if in none of them was a conjecture put at risk of turning out false.

Building to learn demands something more specific and considerably more uncomfortable: knowing what you wanted to find out before the stretch began. Not the feature you wanted to deliver, but the question you wanted to close. Those are two different plans, and the second one almost never gets written. If at the milestone you can say "it works" but you cannot say "we now know that", the stretch produced output rather than knowledge.

Hence the techniques that work best are the ones that make the attempt cheaper without making the evidence cheaper. Bill Buxton insisted that a sketch and a prototype are neither the same thing nor good for the same thing: a sketch suggests and gets discarded, a prototype answers and gets kept. Confusing the two is one of the most efficient ways of spending weeks: building prototypes with the ambition of a product in order to answer questions a sketch would have settled in an afternoon.

Why planning the throwaway is so hard

Brooks puts his finger on the organisational part: the sensible option — planning the throwaway — exists, is well known, and is almost never chosen. It is worth asking why.

The first reason is accounting. A system that will be thrown away shows up as cost; a system that gets delivered shows up as value, even if it is the same system. No investment committee easily approves a line item whose declared deliverable is learning, because learning has no place on the balance sheet and shipped software does. The perverse consequence is that an asset which will have to be rewritten gets preferred over a cost that would have avoided the rewrite.

The second is reputational. Announcing in advance that the first thing you build will be thrown away amounts to publicly admitting you cannot get things right first time. In management cultures where error is administered as personal failure, that is indefensible, even when it is true and even when everyone knows it. It is safer to build the draft quietly and call it version one.

The third is subtler and perhaps the most decisive: a planned throwaway forces you to decide twice. Once when building the pilot and once when deciding what to keep of what you learned. That second decision point is exactly the one overloaded organisations try to avoid, because every decision point consumes the attention of scarce people. Promising the draft to the customer has the advantage of eliminating the second decision: once it is delivered, there is nothing left to decide.

The operational version

None of this asks for a change of method. It asks for a change in what counts as a good result from a stretch of building.

It means entering construction at a scale that still lets you change your mind: concrete enough to produce evidence, coarse enough not to have mortgaged the scope. It means treating the first stretch as what it is, a period of discovering everything that could not be known beforehand, and therefore reserving in advance the possibility that scope will move. It means protecting the moment when someone says that what was built proved the conjecture wrong, because that is the moment the project delivered its highest return and also the moment when most people have an incentive to bury it.

And it means accepting the asymmetry Brooks leaves implicit: the draft is going to get built either way. The only variable you control is who pays for it.

How many of the systems you maintain today are really the pilot nobody dared to throw away?