In March, a former colleague sent me a screenshot. A complete sign-up form, with validation, a database and a confirmation email, generated in thirty seconds. Under the image, a question: “So the project we estimated at eighty days, that’s eight days now?”
I have spent the last few years estimating projects for large companies. It took me a while to answer, because the honest answer is “no”, and it needs explaining.
What people believe
The reasoning looks solid. A project is code. Code is written ten times faster. So the project costs ten times less. And if the estimate does not go down, someone is covering themselves.
It is wrong, but not for the reason usually given. It is not that “code isn’t everything”. It is that code was never what we were estimating.
What eighteen years of estimating taught me
When I break a project down, typing accounts for a fraction of the total. What I price is something else: understanding what the client actually wants, which takes three meetings and two reversals. Waiting for an answer from the IT department about an access. Discovering that the system we need to integrate with does not do what its documentation says. Redoing a screen because the person who will use it had not seen it yet. Checking that it works on the workstation locked down by group security.
The buzzer gave me a miniature version of this. The event handler was written in seconds. The bug that only happened on a Galaxy A33 cost three days, and the tool could do nothing about it: it needed a real phone, a real thumb, and someone noticing that nothing happened.
On an eighty-day fixed-price project, when I look at the ones that went off the rails, none of them slipped on writing code. They slipped on a requirement understood backwards, an environment that was not ready, an integration that did not keep its promises. None of those three sped up. They do not depend on the keyboard.
What it changes in practice
What changed is the proportion. The certain part of the project, the one we knew how to do and just had to write, became almost free. The uncertain part costs exactly what it used to. So the project is a bit cheaper, and proportionally much riskier: what is left is the risk.
When you commit to a fixed price, that imposes three things.
Estimate uncertainty, not volume. Counting screens no longer means anything. Counting the places where we do not know yet does.
Show earlier. If a screen costs an hour, there is no reason left to wait three weeks before showing it to the person who will use it. The reversal costs the same as before; you might as well trigger it on day one.
And reduce what you commit to. A fixed price used to cover two things: known work and a bet on the unknown. The known work is no longer worth much. Staying committed to the bet, at the same price, means keeping all the risk after losing what used to offset it.
I did eventually answer my colleague. It is not eight days. It is maybe sixty, fifty of which do not show up in a screenshot.
We sped up the part of the project we knew how to estimate. The part we didn’t is still there.
Get the journal by email
About one entry a week. What I build, what breaks, what I learn. No promotion, one-click unsubscribe.
You can also follow the RSS feed.