The Estimate Is Not the Fight

The meeting always reaches the same moment. Somebody asks how long this will take, and everyone present understands that the question is not really how long. It is what number can go on a slide. The engineer answering is not estimating a duration. She is choosing a figure she can survive being held to, in a room where the last person who offered an honest range was asked to sharpen it up.

An estimate is a probability distribution. It has a shape, a most likely value, and a long tail off to the right where all the interesting content lives. What gets written down is a single date. The distribution goes into the room and a date comes out, and from that moment the date behaves as a commitment, because a slide has no way to draw a distribution and a quarterly plan has no way to consume one.

Then the loop starts, and it is the most recognizable thing in this whole subject. The engineer adds margin, because the tail is real and she is the one who works the weekend. Product knows margin is in there, so it discounts. The engineer, having watched her margin removed, adds more next time to survive the discount. Product discounts harder. Within a few cycles the number carries no information in either direction: not a forecast, not a commitment, a bid in a negotiation neither side will call a negotiation.

I spent years believing the fix was better estimates. It is not, and the reason is that the estimate is not the disagreement. It is only where the disagreement becomes visible, because it is the one artifact both functions have to sign. Underneath it, the two sides are being measured on different clocks, and the uncomfortable part is that both measurements are correct.

The quarter is not an arbitrary unit. Product is accountable inside it because that is genuinely how a business plans. Budgets are set annually and revised quarterly, hiring is approved against a plan, a board asks what shipped, and a competitor's release arrives on its own schedule regardless. A product manager who answers "sometime next year" has not been admirably careful. They have failed at the actual job, which is converting uncertainty into something the business can decide against.

The four-year system is not a fantasy either. Engineering is accountable for something that still has to be changeable in four years, and nearly nothing protecting that shows up inside any quarter you could name. The suite that stayed fast, the interface that did not leak, the dependency upgrade taken while it was still routine. Each is invisible when it works, and the bill for skipping it arrives years later, attached to a different quarter and usually a different manager.

Barry Boehm published the shape in Software Engineering Economics in 1981, and Steve McConnell later gave it the name everyone uses: the cone of uncertainty. Drawn as a funnel, wide at the feasibility stage and narrowing as decisions get made and options close off. Read at speed it appears to say that an estimate gets better because time has passed. That reading is what the sentence "we will have a better number after discovery" is quietly standing on.

In the May/June 2006 issue of IEEE Software, Todd Little published data from Landmark Graphics against that idea: 106 commercial projects tracked weekly from 1999 to 2002, average duration 329 days, estimates revised roughly eight times over a project's life, so these are year-long efforts re-forecast repeatedly rather than two-week tickets. The ratio of actual duration to initial estimate came out lognormal, median around 1.8 and mean around 2.0. The old joke about doubling the estimate turns out to be the median behavior of a hundred real projects.

The finding that matters is the second one. When Little plotted remaining actual duration against remaining estimated duration, the distributions at each project phase were nearly identical, holding at roughly a factor of three to four between the tenth and ninetieth percentiles from the first week to the last. Uncertainty about what was left did not shrink as the work progressed. What converges at the end is the total, and the total has no choice, because the project stops. He calls the resulting shape a pipe rather than a cone.

That needs holding at the right weight. It is one company, in oil and gas software, over three years, and Little says so himself: one company's data may not extrapolate. His paper also opens on a Standish CHAOS figure, which Magne Jorgensen and Kjetil Molokken-Ostvold took apart that same year in Information and Software Technology, so the framing is weaker than the data underneath it. What makes it hard to dismiss is that these were not poor estimators. On DeMarco's estimation quality factor, Landmark's median sat above the industry median he had published.

Here is what the metaphor originally said. Ward Cunningham used it in an experience report at OOPSLA in 1992 about a portfolio management system: shipping first-time code is like going into debt, and a little debt speeds development so long as it is paid back promptly with a rewrite. In a video in 2009 he was blunter still that it was never a license for bad code. The debt he meant was the distance between the program and what the team had since come to understand about the problem, which is a specific and diagnosable condition.

And that is exactly why it gets discounted. The term now covers all of that and a module written by somebody who left, and product is right to discount it. If one phrase covers both "we cannot ship the next three features until this is dealt with" and "I would have written it differently", then the only rational response to the phrase is to ignore it and ask what is behind it. Engineering experiences that as not being listened to. It is closer to a correct response to a broken signal, and the signal was broken by the people sending it.

The fix is a price, not a better metaphor. Two questions make a request evaluable. What is this costing us per month right now, and what does it cost if we do nothing about it for a year. The answers can be rough and should be honest about how rough. "Every change to billing takes three days instead of half a day, and we make about ten of them a month" is a sentence a product manager can weigh against a feature and sometimes decide against, which is the point. "We have technical debt in billing" cannot be weighed against anything.

A date is missed. Nobody was malicious and usually nobody was careless. The response is more oversight: a weekly status, a finer-grained breakdown, a re-estimate at a level of detail nobody required last quarter. Each of those is what a responsible manager does after a miss. That is what makes the loop hard to interrupt - there is no step in it you can point at and call unreasonable.

The oversight then comes out of the thing it is measuring. Re-estimation, status reporting and the meeting to explain the variance are drawn from the same hours that would have gone into the work, and they come disproportionately from the senior people whose attention was already the binding constraint. So the next date is set with less information and pursued with less capacity, and it slips too, which produces more oversight.

Underneath all of it sits a question nobody wants on their desk, which is who is allowed to say no. When that belongs to nobody in particular, every request gets answered with a qualified yes, and the qualification quietly turns into a date on its way to the slide. The date is the lie. It is usually not told by the person who said it out loud; it is told by a structure that had no way of producing a no.

To product, done means a user can do the thing. To engineering, done means a user can do the thing, and it emits enough signal to debug at three in the morning, and somebody who is not the author can be paged for it, and the next change to it will not be an archaeology project. Those are not the same quantity of work. The second is frequently half again the first, and every bit of the difference is invisible in a demo.

Product is not wrong to want the first one sooner, and I have been on the wrong side of this. A feature nobody uses does not need to be observable. Building the durable version of something before knowing whether anyone wants it is not rigor, it is an expensive way of postponing a question, and the right answer to "will people use this" is almost always to find out with the cheapest artifact that can answer it.

Put engineers in discovery early enough to change what gets built. The highest-leverage change available, and it costs product some control, which is why it is rare. If engineering first sees a proposal when it arrives as a specification, the only remaining variable is how, and how is where the expensive parts were already decided. Brought in while the what is still open, an engineer can point out that the second version of a requirement costs a fifth of the first. That is a conversation about scope rather than schedule, and it is the only one that reliably saves real time.

Replace dates with ranges and a named review point. For anything genuinely uncertain. "Between six and ten weeks, and we will know which by the end of week three, when the migration either works or does not" is more useful to a business than a date, because it says what will be known and when. The review point is what makes it a commitment rather than a hedge, and it is the part engineers most often leave off. Basecamp's Shape Up pushes the idea further, fixing the time and varying the scope, and calling the fixed figure an appetite rather than an estimate.

Separate the estimate from the commitment out loud. When a number is asked for, ask what it is for. A figure that informs a sequencing decision can be rough and should be handed over in minutes. A figure that goes to a customer or into a board deck is a different object and deserves a different conversation, and it is entirely fair to ask for time to produce it. Most of the estimation damage I have watched came from the first kind being harvested and then used as the second.

Engineers are frequently wrong about what matters. The instinct that the system is the thing being built is only sometimes right, and I have watched teams, mine included, spend months on a generalization for a second use case that never arrived, on a configuration surface nobody asked for, and on making something fast that nobody was waiting on. Product's impatience is often just accuracy about which parts of the work will turn out to matter, and it has saved companies from a year spent polishing something nobody wanted.

"Let us rewrite it" has burned more organizations than any deadline ever has. It is the most expensive sentence in the profession and it is almost always offered in good faith: a proposal to spend a year reproducing behavior nobody wrote down, in order to reach parity with a system that has been absorbing corrections for a decade, while the people who wanted features wait. I have made that argument. I was wrong, and I was completely sincere, which is the part worth noticing. Sincerity is not evidence.

The one I would press hardest is this. Engineering's inability to price its own work in terms a business can weigh is a professional failing, not a communication gap, and calling it a gap in communication is how the profession has avoided fixing it for forty years.

Every other function that asks for money can say what the money buys. Finance, marketing, sales and legal each have an accepted way to put a request in the currency of the business. Engineering asks for time, describes what it will do with it in its own vocabulary, and is offended when the request loses to one carrying a number.

A function that cannot explain its own costs gets managed by people who guess at them, and it has earned that. Which makes my thesis smaller than I would like. I opened by calling this a difference in incentive rather than understanding, and I still think that is true of why the conflict exists. It is not true of how bad it gets. A large share of the severity is engineering failing at a job that belongs to engineering, and that part is not structural. It is simply not being done.

I should be careful with one thing I said early on. Treating this as a communication problem guarantees it recurs, but it does not follow that communication is worthless, and most of what I listed as relief is communication: earlier, in a different room, in a different vocabulary, with the disagreement made explicit rather than resolved. What fails is the other version, where two functions are put in a workshop to understand each other better. They already understand each other perfectly well. Understanding does not change what either of them is paid on.

The estimate will go on being where the fight happens, because it is the only artifact both sides have to sign, and a signature is where a disagreement stops being private. It is not where the disagreement lives. Arguing about the number is arguing about the thermometer, and if you win that argument, what you will have is a more accurate reading of a room that is still the wrong temperature.