Someone asks how long it will take. You say six weeks. You didn't count anything to get there. You looked at the work, remembered the last time something like it went sideways, added a little for the meetings, and picked the first serious-sounding number that wouldn't get you laughed out of the room.
By Friday it's on a slide. A month later someone in finance is tracking it against actuals, and nobody remembers it started as a shrug.
The whole company runs on these numbers. The sprint, the roadmap, the date sales already gave a customer who is now waiting on it. None of it is knowledge. It is a pile of guesses everyone agreed to trust, because the alternative was saying out loud that nobody knows.
You estimate because building is expensive, and you can't spend that kind of money blind. That was the reason, the only one. It stopped being true a while ago, and nobody canceled the meeting.
The number used to be worth something. Software got built the way a house gets built, slowly and for real money, and once the foundation was poured you lived with it. You couldn't run the project twice. So you did what a contractor does before breaking ground: you added it up, roughly, and decided whether it was worth doing at all.
Nobody thought the estimate was accurate. It only had to be close enough to say yes or no, and back then it was, because the work crawled. A number could stay true for months, because months was how long everything took. You were pricing a decision you couldn't undo, and a rough price was enough to make the call.
Building was the costly, one-way part, so you did your thinking early, on paper, where nothing was locked yet. You only got to build it once, so you thought about it first.
Now you get to build it as many times as you like. The machine writes the six-week feature in an afternoon. If it comes out wrong, you throw it away and build a different one before dinner. Building is not the expensive part anymore. Most weeks it is the cheapest thing you do.
Which means the meeting to size the work now costs more than the work. You put six engineers in a room to argue a number onto the six-week feature, and the argument runs past lunch. The machine built the thing while you were arguing. It was done before you agreed on the number.
When guessing how long a thing will take costs more than doing the thing, the guess has no reason to exist. And the estimate was never even good, back when you had no choice.
The people who study this at scale have the numbers. Nine of every ten megaprojects come in over budget, most of them late as well, and the pattern has held for seventy years across every country that keeps records. The Channel Tunnel ran eighty percent over budget. The Big Dig, two hundred and twenty. The Sydney Opera House, fourteen hundred. These are the most carefully planned undertakings on earth, run by people with everything to lose and armies of estimators, and they miss anyway, almost every time. Estimating was never a skill you were short on. It does not reliably work, and building used to cost enough that you did it anyway.
So why is the meeting still on the calendar? Because the estimate was never really about time. It is about who gets to run work they cannot judge. A manager who has never read the code cannot tell you whether it is good. They can tell you whether it is late. The number is the only handle they have on the work, and they are not giving it up because building got fast.
The number becomes the thing everyone manages instead of the work. Sprints, burndowns, velocity, the roadmap review: the whole apparatus exists to keep a date bolted to work nobody at the table could otherwise grade. It is not planning. It is a way to hold engineering accountable without having to understand it.
That control has a price, and you pay it in the work. You set the number in week one, when you knew the least you ever would about the job. In week three you find out the thing you are building is not the thing anyone needed. But the date is on the roadmap, and missing it is the one failure everyone can see, so you keep building the week-one version, the one you now know is wrong, because it is the one you promised.
An estimate is a promise to stop learning.
And you keep it, which is the strange part. You learn something every week, and you ship the decision you made in the dumbest one.
So kill the estimate. Not estimate better, not in smaller batches. Kill it. Stop asking how long a thing will take, and go find out the only way that ever worked, by building it.
You have something the old world never did. You can build the thing to see what it is. Not a spec of it, not a mockup, the thing, working, by Thursday. Build it three ways if you are not sure, keep the one that is right, and delete the other two. The plan stops being a promise you defend and becomes a question you answer by building.
The business will say it needs the date. It doesn't. It needs to know the thing is real and on its way, and you can show it that this week instead of promising it in six. A working slice they can click beats any number on a roadmap. Give them proof and they stop asking for the promise.
Watch who fights hardest to keep the estimate. The engineer who cannot build fast wants the six weeks to hide in. The manager who cannot judge the work wants the number to hold you to. And the firm across the table wants it most, because the estimate is the whole thing it sells: the statement of work, the fixed bid, the roadmap with your logo on it, a promise about a future no one can see, billed by the hour. They sell certainty because they cannot sell the thing. You can just build the thing.
We build. They bill.