The cost of building the wrong thing quickly
Speed only helps once you know what you are building. Before that, it just gets you to the wrong place sooner.
Everything about how we build software has got faster. Scaffolding a project takes a minute. Generating a component takes seconds. Shipping is a push.
None of that speed helps with the part that actually decides whether the work was worth doing.
Two different kinds of slow
There is the slow that comes from friction: waiting on a build, fighting a deployment, rewriting something for the third time because nobody wrote down the decision. That kind of slow is pure loss, and it is worth spending real money to remove.
Then there is the slow that comes from thinking. Sitting with a problem before choosing an approach. Talking to the person who has the problem. Deciding what to leave out.
The first kind of slow is waste. The second kind is the work.
The trouble is that both look identical on a burndown chart, so the pressure to remove friction tends to remove thinking too.
What cheap production changes
When building was expensive, the cost of building the wrong thing was obvious. You felt it. That expense functioned as a crude filter: some bad ideas were simply too costly to attempt.
That filter is gone. The bad idea and the good idea now cost about the same to produce, which means the filter has to move earlier, into judgement. And judgement is exactly the thing that does not get faster.
What I try to do about it
I try to keep the expensive part expensive on purpose. Before building, I want to be able to answer three questions in one sentence each:
- Who has this problem, and what do they do today instead?
- What would have to be true for this to be worth their while?
- What is the smallest thing that would tell us whether that is true?
If I cannot answer those, more speed is not going to help. It will just produce a well-built answer to a question nobody asked.
The goal was never to build faster. It was to spend less of my life on things that did not need to exist.