{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"estimation-and-the-demo-effect","title":"Why everything looks nearly done","url":"https://addaly.com/learn/how-software-changed/estimation-and-the-demo-effect","position":52,"of":87,"minutes":9,"answer":"The demo now arrives on day one and completion takes as long as it ever did, so estimate by counting unresolved decisions against a reference class of past work.","keyIdea":"The demo now arrives on day one and completion takes as long as it ever did, so estimate by counting unresolved decisions against a reference class of past work, state the estimate to deployed rather than to demo, and put the edge cases on the board before anybody sees it working."},"body":{"format":"markdown","text":"## The shape of the new estimate error\n\nThe first 80% of a feature now takes an hour. The last 20% takes the three weeks it always took.\n\nThat is the whole lesson, and everything else is a consequence. A working demo exists on day one: the screen renders, the happy path works, somebody can click through it. What remains is the part that was always the work: the empty state, the concurrent edit, the migration for existing rows, the permission rule, the failure of the service it depends on, the case where the customer has 4,000 of them, and integrating with the thing another team is halfway through changing.\n\nSo the estimate error changed shape. It used to be roughly proportional: a task estimated at two days took three. Now it is bimodal: a task looks finished on day one and completes on day fifteen, and the gap between those two dates is invisible from outside.\n\n> Figure: The demo and the remainder. A two by two grid, rows The first eighty per cent and The last twenty per cent, columns How long it takes and How it looks from outside: The first eighty per cent and How long it takes: About an hour; The first eighty per cent and How it looks from outside: Nearly finished; The last twenty per cent and How long it takes: The three weeks it took before; The last twenty per cent and How it looks from outside: Stalled. The estimate error stopped being proportional and became bimodal. Write the edge cases on the board on day one, before anybody has seen the thing work and while expectations are still adjustable.\n\n## Why this damages more than a plain overrun\n\n**Stakeholders saw the demo.** Once somebody has watched the feature work, \"three more weeks\" sounds like an excuse rather than a description. This is a communication problem created by the tooling and it needs handling before the demo, not after.\n\n**Your own judgement is affected too.** You have seen the thing working. The remaining work is abstract and the completed work is vivid, and the ratio between them feels smaller than it is.\n\n**The remaining work is the hard work.** Not merely the last fifth by volume: the fifth that requires understanding the system, deciding edge cases and integrating with reality. It is also the fifth that is slowest to verify.\n\n## Estimating anyway\n\n**Count the unknowns, not the code.** The question is not how big the change is. It is how many things nobody has decided yet. Run the ambiguity audit; each unresolved item is a source of variance, and a task with nine of them is not a two-day task whatever its size.\n\n**Use reference classes, not intuition.** Do not ask how long this will take. Ask how long the last five things that resembled it took. Your issue tracker holds this and almost nobody looks. Reference-class forecasting outperforms expert judgement consistently, and it is a database query.\n\n**Split until you can count.** If a piece cannot be described in one sentence without \"and\", split it. Keep splitting until every piece is something you have done a version of before. Then the reference class works.\n\n**Estimate to deployed, not to demo.** Say so explicitly. \"Two days to something you can look at, two weeks to something customers can use\" is an honest sentence and it sets the expectation at the right moment.\n\n**Add the integration tail deliberately.** Migration, flag, rollout, monitoring, the support team knowing, the old path deleted. This list is roughly constant per feature and it is what is missing from almost every estimate.\n\n## The sentence to use\n\nWhen the demo goes well and somebody asks whether it is nearly done, the useful answer is specific rather than defensive:\n\n> The happy path works. Still to do: what happens when a customer has none of these, what happens when two people edit at once, the migration for the 40,000 existing rows, and the permission rule for agency accounts. That is about two weeks, mostly on the migration.\n\nThat answer is credible because it is enumerable. \"It's more complicated than it looks\" is not, and it is what people say when they have not made the list.\n\n## The 90/90 rule, updated\n\nTom Cargill's old joke (the first 90% of the code takes 90% of the time and the remaining 10% takes the other 90%) was funny because it was recognisable. It is now closer to arithmetic than to satire.\n\nThe underlying reason has not changed since he said it. Essential complexity is the part that resists, and the current wave removed accidental complexity faster than any previous one. The visible portion of the work shrank; the invisible portion did not; the ratio between them got worse.\n\nWhich means the honest planning move is to make the invisible portion visible early. Write the edge cases on the board on day one, before the demo, while nobody has yet seen the thing work and everybody's expectations are still adjustable."},"check":{"question":"A team demos a feature on day two. The manager schedules the launch for the following week. The team says it needs three more weeks. Which practice would most reliably have prevented the disagreement?","options":[{"text":"Not demoing until the feature is complete, so expectations are never set by partial work.","correct":false,"tempting":"Removes the disagreement by removing the feedback, which is one of the genuine benefits of an early working path."},{"text":"Estimating in story points rather than dates, so the conversation stays about relative size instead of calendar time.","correct":false,"tempting":"Abstraction postpones the conversation rather than resolving it; the manager still needs a date and will infer one from the demo."},{"text":"Enumerating the remaining edge cases and integration work before the demo, and stating the estimate to deployed.","correct":true},{"text":"Tracking the proportion of past features whose post-demo work exceeded the pre-demo work, and quoting the ratio.","correct":false,"tempting":"A genuinely useful reference class, but a ratio persuades less than a specific enumerated list of what is left."}]},"prev":{"slug":"measuring-delivery-not-activity","title":"Four numbers that resist gaming","url":"https://addaly.com/learn/how-software-changed/measuring-delivery-not-activity"},"next":{"slug":"work-in-progress-limits","title":"Capping the queue","url":"https://addaly.com/learn/how-software-changed/work-in-progress-limits"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Why everything looks nearly done', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/estimation-and-the-demo-effect (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Why everything looks nearly done","courseTitle":"How Software Development Changed","module":{"index":6,"slug":"teams-and-delivery","title":"Teams, process and delivery"},"answer":null,"keyIdea":"The demo now arrives on day one and completion takes as long as it ever did, so estimate by counting unresolved decisions against a reference class of past work, state the estimate to deployed rather than to demo, and put the edge cases on the board before anybody sees it working.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"cols":["How long it takes","How it looks from outside"],"rows":["The first eighty per cent","The last twenty per cent"],"type":"matrix","cells":[["About an hour","Nearly finished"],["The three weeks it took before","Stalled"]],"title":"The demo and the remainder","caption":"The estimate error stopped being proportional and became bimodal. Write the edge cases on the board on day one, before anybody has seen the thing work and while expectations are still adjustable.","cellLabels":[["the screen renders and the happy path works","and stakeholders have now watched it work"],["empty state, concurrent edit, migration, permission rule, the dependency mid-change","so three more weeks sounds like an excuse"]]},"alt":"Figure: The demo and the remainder. A two by two grid, rows The first eighty per cent and The last twenty per cent, columns How long it takes and How it looks from outside: The first eighty per cent and How long it takes: About an hour; The first eighty per cent and How it looks from outside: Nearly finished; The last twenty per cent and How long it takes: The three weeks it took before; The last twenty per cent and How it looks from outside: Stalled. The estimate error stopped being proportional and became bimodal. Write the edge cases on the board on day one, before anybody has seen the thing work and while expectations are still adjustable."}},"blocks":[{"t":"h2","id":"the-shape-of-the-new-estimate-error","runs":[{"text":"The shape of the new estimate error"}]},{"t":"p","runs":[{"text":"The first 80% of a feature now takes an hour. The last 20% takes the three weeks it always took."}]},{"t":"p","runs":[{"text":"That is the whole lesson, and everything else is a consequence. A working demo exists on day one: the screen renders, the happy path works, somebody can click through it. What remains is the part that was always the work: the empty state, the concurrent edit, the migration for existing rows, the permission rule, the failure of the service it depends on, the case where the customer has 4,000 of them, and integrating with the thing another team is halfway through changing."}]},{"t":"p","runs":[{"text":"So the estimate error changed shape. It used to be roughly proportional: a task estimated at two days took three. Now it is bimodal: a task looks finished on day one and completes on day fifteen, and the gap between those two dates is invisible from outside."}]},{"t":"h2","id":"why-this-damages-more-than-a-plain-overrun","runs":[{"text":"Why this damages more than a plain overrun"}]},{"t":"p","runs":[{"text":"Stakeholders saw the demo.","b":true},{"text":" Once somebody has watched the feature work, “three more weeks” sounds like an excuse rather than a description. This is a communication problem created by the tooling and it needs handling before the demo, not after."}]},{"t":"p","runs":[{"text":"Your own judgement is affected too.","b":true},{"text":" You have seen the thing working. The remaining work is abstract and the completed work is vivid, and the ratio between them feels smaller than it is."}]},{"t":"p","runs":[{"text":"The remaining work is the hard work.","b":true},{"text":" Not merely the last fifth by volume: the fifth that requires understanding the system, deciding edge cases and integrating with reality. It is also the fifth that is slowest to verify."}]},{"t":"h2","id":"estimating-anyway","runs":[{"text":"Estimating anyway"}]},{"t":"p","runs":[{"text":"Count the unknowns, not the code.","b":true},{"text":" The question is not how big the change is. It is how many things nobody has decided yet. Run the ambiguity audit; each unresolved item is a source of variance, and a task with nine of them is not a two-day task whatever its size."}]},{"t":"p","runs":[{"text":"Use reference classes, not intuition.","b":true},{"text":" Do not ask how long this will take. Ask how long the last five things that resembled it took. Your issue tracker holds this and almost nobody looks. Reference-class forecasting outperforms expert judgement consistently, and it is a database query."}]},{"t":"p","runs":[{"text":"Split until you can count.","b":true},{"text":" If a piece cannot be described in one sentence without “and”, split it. Keep splitting until every piece is something you have done a version of before. Then the reference class works."}]},{"t":"p","runs":[{"text":"Estimate to deployed, not to demo.","b":true},{"text":" Say so explicitly. “Two days to something you can look at, two weeks to something customers can use” is an honest sentence and it sets the expectation at the right moment."}]},{"t":"p","runs":[{"text":"Add the integration tail deliberately.","b":true},{"text":" Migration, flag, rollout, monitoring, the support team knowing, the old path deleted. This list is roughly constant per feature and it is what is missing from almost every estimate."}]},{"t":"h2","id":"the-sentence-to-use","runs":[{"text":"The sentence to use"}]},{"t":"p","runs":[{"text":"When the demo goes well and somebody asks whether it is nearly done, the useful answer is specific rather than defensive:"}]},{"t":"quote","runs":[{"text":"The happy path works. Still to do: what happens when a customer has none of these, what happens when two people edit at once, the migration for the 40,000 existing rows, and the permission rule for agency accounts. That is about two weeks, mostly on the migration."}]},{"t":"p","runs":[{"text":"That answer is credible because it is enumerable. “It’s more complicated than it looks” is not, and it is what people say when they have not made the list."}]},{"t":"h2","id":"the-90-90-rule-updated","runs":[{"text":"The 90/90 rule, updated"}]},{"t":"p","runs":[{"text":"Tom Cargill’s old joke (the first 90% of the code takes 90% of the time and the remaining 10% takes the other 90%) was funny because it was recognisable. It is now closer to arithmetic than to satire."}]},{"t":"p","runs":[{"text":"The underlying reason has not changed since he said it. Essential complexity is the part that resists, and the current wave removed accidental complexity faster than any previous one. The visible portion of the work shrank; the invisible portion did not; the ratio between them got worse."}]},{"t":"p","runs":[{"text":"Which means the honest planning move is to make the invisible portion visible early. Write the edge cases on the board on day one, before the demo, while nobody has yet seen the thing work and everybody’s expectations are still adjustable."}]}],"check":{"question":[{"text":"A team demos a feature on day two. The manager schedules the launch for the following week. The team says it needs three more weeks. Which practice would most reliably have prevented the disagreement?"}],"options":[{"text":[{"text":"Not demoing until the feature is complete, so expectations are never set by partial work."}],"correct":false,"tempting":[{"text":"Removes the disagreement by removing the feedback, which is one of the genuine benefits of an early working path."}]},{"text":[{"text":"Estimating in story points rather than dates, so the conversation stays about relative size instead of calendar time."}],"correct":false,"tempting":[{"text":"Abstraction postpones the conversation rather than resolving it; the manager still needs a date and will infer one from the demo."}]},{"text":[{"text":"Enumerating the remaining edge cases and integration work before the demo, and stating the estimate to deployed."}],"correct":true,"tempting":null},{"text":[{"text":"Tracking the proportion of past features whose post-demo work exceeded the pre-demo work, and quoting the ratio."}],"correct":false,"tempting":[{"text":"A genuinely useful reference class, but a ratio persuades less than a specific enumerated list of what is left."}]}],"order":[0,1,2,3],"why":null},"prev":{"slug":"measuring-delivery-not-activity","title":"Four numbers that resist gaming","minutes":10},"next":{"slug":"work-in-progress-limits","title":"Capping the queue","minutes":9}}}