I’ve been thinking again about the old engineering advice:
“Build one to throw away. You will anyway.”
The phrase is often attributed to Fred Brooks, although versions of the idea appear throughout engineering culture. I first encountered it in discussions of hardware and industrial design, where it is common to build rough physical prototypes out of cardboard, foam, or scrap material before committing to expensive tooling and manufacture.
These rough prototype exist to answer questions like:
- Does this shape actually make sense in the hand?
- Is this arrangement awkward?
- Are we solving the correct problem?
- What assumptions break when exposed to reality?
The interesting thing about these prototypes is that everybody already understands that they are provisional. Nobody mistakes the cardboard mock-up for the final product.
Software is theoretically even better suited to this kind of exploration. Git branches are cheap. Directories are cheap. Refactoring tools are cheap. And now AI systems can generate large variations of implementations almost instantly.
And yet, despite repeatedly advocating for generating alternatives and exploring solution spaces, I’ve realised that I rarely build genuinely competing implementations myself.
That observation bothered me.
“Once it works, we don’t want to change it”
I started thinking about this again after rereading this 2020 blog post by George Stocker discussing the phrase in the context of TDD. One line in particular resonated with me:
“Once it works, we don’t want to change it.”
That feels profoundly true.
The moment software works, it undergoes a psychological transformation. It stops feeling like an experiment and starts feeling like the solution.
I think several cognitive biases suddenly snap into place simultaneously.
The first is the endowment effect. Humans consistently overvalue things they already possess relative to equivalent alternatives. A working implementation feels valuable partly because it already exists.
The second is the sunk cost fallacy. Every ugly workaround, every debugging session, every hard-earned insight starts exerting pressure against restarting or exploring alternatives. The pain invested in the system becomes an argument for preserving it.
And then there is perhaps the strongest force of all: confirmation bias.
A working system is extraordinarily persuasive evidence. It screams “See? It works.”
But it only proves one thing: that the approach is possible.
It does not prove:
- that the architecture is good,
- that the design is maintainable,
- that the constraints were properly understood,
- or that the design space was adequately explored.
And yet psychologically it feels like confirmation that we are “on the right track”. I’ve marked students down for this mistake of going for the first thing that worked in designs many times.
The four-card problem
I recently watched a discussion of the famous four-card reasoning task developed by Peter Wason.
You are shown four cards. Each card has a letter on one side and a number on the other. You are told a rule such as:
“If a card has a vowel on one side, then it has an even number on the other.”
The task is to decide which cards must be turned over to test the rule.
Most people choose cards that could confirm the rule rather than cards that could falsify it.
The correct reasoning is subtle. To test the statement properly, you must actively search for disconfirming evidence.
This is deeply unintuitive for humans.
Science itself is largely a cultural technology built around compensating for this weakness. Hypothesis testing, controls, replication, adversarial review — these are all mechanisms designed to force us into falsification-oriented thinking because it does not come naturally.
And software engineering is not immune.
A working prototype is the ultimate confirmatory evidence:
“Look, this can solve the problem.”
But perhaps the more important question is:
“What competing approaches did we fail to seriously investigate because this one started working first?”
The multiverse problem
I suspect there is also a cognitive limitation here that goes beyond simple bias.
Technically, maintaining alternatives is cheap, but mentally, it is expensive.
Once I have a project directory in front of me, I naturally start treating it as the canonical reality instead of one branch in a multiverse of possibilities.
I think this is one reason software exploration is harder in practice than it appears in theory.
We often talk as if software design is just a search problem:
- Generate alternatives.
- Evaluate alternatives.
- Select the best one.
But this assumes we can stably maintain several competing models simultaneously in our minds.
In practice, I think humans collapse possibility space very early.
As soon as one approach accumulates enough detail, enough code, enough explanatory coherence, it becomes psychologically privileged. Alternative realities become harder to inhabit sincerely.
This is perhaps why teams frequently outperform individuals on exploratory work. Different people can independently inhabit different solution spaces. One engineer can become convinced that event sourcing is the correct architecture while another sincerely explores a relational approach. Their disagreement preserves diversity in the search space.
An individual mind struggles to do this honestly. Once we commit to a narrative, alternatives start feeling like attacks on accumulated understanding rather than legitimate possibilities.
The Joel Spolsky tension
Of course, the opposite failure mode also exists.
Joel Spolsky’s famous essay Things You Should Never Do, Part I argues strongly against rewriting software from scratch. His argument is often caricatured, but there is an important truth in it: long-running systems encode enormous amounts of tacit knowledge.
A mature system is not merely source code. It is a fossil record of collisions with reality.
That bizarre validation rule probably exists because of a customer incident from 2017. That ugly retry loop may encode a production failure nobody fully remembers. That seemingly unnecessary timeout might represent weeks of operational pain.
Rewrites often erase knowledge faster than they create clarity.
And so there is a genuine tension here:
- explore too little and you prematurely lock into mediocre designs,
- explore too much and you repeatedly discard hard-earned knowledge.
The ideal time to throw something away may actually be immediately after proving it works — exactly the moment humans least want to do so.
AI and the explosion of possibility
I think modern AI systems may amplify this entire dynamic dramatically.
For years, generating serious alternative implementations was expensive enough that most teams simply could not afford much exploration. The first plausible architecture naturally won by default.
But now the economics are changing.
You can ask an AI assistant to
- generate a second implementation,
- refactor toward a different architecture,
- prototype an entirely different interaction model,
- or produce multiple candidate APIs,
in minutes.
The cost of generating alternatives is collapsing.
But our cognitive habits have not changed nearly as quickly.
We still emotionally anchor on the first thing that works.
In fact, AI may make this worse. A compelling demo exerts enormous gravitational pull. Once stakeholders can click buttons and see behaviour, the prototype rapidly acquires political and emotional inertia regardless of architectural quality. I’ve seen this cut both ways, because early prototypes can also elicit disproportionally intense critiques of minor details.
The prototype becomes real long before it becomes good.
Designing systems around bias
In general, knowing about human cognitive bias is only useful if we build systems around it.
- Procurement processes often require three competing quotes because we know people anchor too quickly on the first acceptable option.
- Science forces replication and adversarial review because individual researchers cannot reliably falsify their own ideas.
- Checklists exist because memory is unreliable.
- Code review exists because authors are blind to their own assumptions.
- Prediction logs and notebooks exist because humans rewrite their own history after outcomes occur.
Perhaps software exploration deserves similar institutional support.
If generating alternatives is becoming dramatically cheaper, maybe we should sometimes require competing prototypes before committing to a direction.
Not because prototypes are precious.
But because working software is such dangerously convincing evidence.
