Key takeaways
- The cost of building software has collapsed; the cost of deciding what to build has not.
- When execution is cheap, the expensive mistake is building the wrong thing well.
- Judgement, taste and problem selection are the scarce inputs — not implementation speed.
- The practical consequence: spend proportionally more on definition and validation, less on the first build.
For most of the history of software, the binding constraint was construction. Ideas were cheap and plentiful; turning one into working software was slow, expensive and uncertain. Every methodology we inherited — estimation, sprints, phased delivery, change control — exists to manage the risk of that construction step.
That constraint has moved. Not disappeared, but moved. Building the thing is now the fastest and most predictable part of the process, and the slowest part is deciding what the thing should be.
When building was expensive, the costly error was underestimating. You would commit to a number, discover the work was twice that, and spend the difference. Everything in a delivery process was designed to catch that.
When building is cheap, that error still exists but it hurts less. The expensive error is different: it is building the wrong thing efficiently. Shipping quickly, competently, and to specification — a product nobody wanted.
Speed is only an advantage if you are pointed in the right direction. Otherwise it is just an efficient way to be wrong.
This is not a new observation. What is new is the ratio. When implementation took nine months, spending three weeks on problem selection felt proportionate. When implementation takes six weeks, three weeks of thinking looks like half the project — and gets cut first, precisely when it has become the most valuable part.
It is worth being specific about what actually got cheaper, because the change is not uniform. Writing code got dramatically cheaper. So did scaffolding, boilerplate, integration glue, tests, and the long tail of mechanical work that used to fill a schedule.
What did not get cheaper: understanding a business well enough to model it. Noticing that two stakeholders mean different things by the same word. Knowing which of the forty requested features are load-bearing. Deciding what to leave out. Judging whether a problem is painful enough that someone will change their behaviour to solve it.
Those are all judgement, and judgement has not been automated. It has been made more valuable, because everything around it got faster.
If you accept the argument, the consequence is fairly mechanical: shift budget from the first build toward definition and validation. Spend real money working out what to build before you build it, and treat that as a deliverable rather than free pre-sales. Make the first build deliberately smaller than feels comfortable, because its job is to answer a question rather than to be the product. Agree in advance what would tell you to stop. And be honest that the riskiest assumption in most projects is commercial, not technical, so testing it should come first.
None of this is novel advice. It is just that the arithmetic behind it has changed enough that ignoring it has become considerably more expensive.
Optimistically, I think it makes the work better. Less of a career is spent on mechanical implementation and more on the interesting part — the part where you sit with someone, understand what they are actually trying to do, and work out the smallest true version of it. That was always the good bit. It is now also the valuable bit.