I checked 14,210 tasks. Then I tried to prove myself wrong.
A software feature does not have a finish date. It has a range of possible ones, and a chance attached to each.
I know because I spent my summer evenings reconstructing all 14,210 tasks from one of the best-documented software projects I could find, which is hard to explain at parties.
I started because of a question I keep hearing in the companies I work with, usually from sales, sometimes from marketing, always at high volume: why is the development team so slow? A date slips. A deal wobbles. Development is asked for a new estimate, and this time, please, one we can actually rely on.
Underneath that request sits an assumption: every feature has one correct duration, and a good-enough team can find it.
It can't. Not because the team isn't good enough. Because the duration isn't there to be found.
The cleanest records I could find
High in the Chilean Andes stands the Vera C. Rubin Observatory. Its software teams spent more than a decade building the systems that turn a nightly flood of sky images into science. The work had federal funding, formal controls, external scrutiny, and more documentation than most companies will ever produce. Because it is science, the project also left unusually complete public records.
Its handbook described a simple five-step process: plan the work, build it, review it, approve it, done. I reconstructed six years of its records and checked how the work actually moved.
Only 3,853 of 14,210 tasks, or 27 percent, followed those five steps in the prescribed order. The others strayed, most of them onto one of 175 other routes. If we cannot even know which route the work will take, an exact arrival time is already suspect.
But that comparison is unfair. These were thousands of different tasks. Some were inevitably larger or stranger than others.
So I made it stricter.
The estimate was the same. The time wasn't.
I looked only at the same kind of development work. Then only at tasks the developers had given exactly the same estimate. Then only at tasks whose estimate was never changed. Finally, only at tasks that followed the handbook's five steps in order. That left 880 tasks that looked about as comparable as real software work gets.
More than a third of those 880 tasks were finished within a day, and half within three days. But fourteen in every hundred were still unfinished after thirteen days. Five in every hundred were still unfinished after twenty-eight.
Same kind of work. Same estimate. Same process. Radically different finish times.
There was an obvious objection. This was scientific software built for an observatory. Maybe ordinary commercial software behaves differently. So I repeated the analysis on two projects run by commercial software companies: the system MongoDB uses to test software changes, and Appcelerator Studio, a tool for building mobile apps. Their teams estimated differently and followed different processes. The exact numbers changed.
The pattern did not.
Even when I compared work with the same estimate that followed the same route from start to finish, the slower tasks still took several times longer than the typical one.
Larger estimates generally did take longer, so the developers were not picking numbers out of a hat. The estimate contained useful information.
It just wasn't a finish date.
How a reasonable estimate becomes an unreasonable promise
Now scale that up. A feature on the roadmap is a hundred tasks like these, estimated one by one, added together, divided across the team. Twelve weeks, say. The result feels mathematical. It isn't a forecast.
A feature is not finished when its typical task is finished. It is finished when its last necessary task is finished. The last tasks are where the range becomes painful. In the observatory data, five in every hundred were still open after twenty-eight days, on work that usually took three.
That is how a hundred individually reasonable estimates produce one deeply unreliable date. The twelve-week date may be possible. The calculation simply hasn't told us how likely it is.
One date hides the decision
This is where development dates go wrong. Development gives its best estimate. Product puts it on the roadmap. Marketing plans a launch. Sales tells a client. Finance starts expecting the revenue.
At every step, the uncertainty falls away.
What began as "probably around October" becomes "October" and eventually "promised for October." When October passes, development is called slow. It wasn't. The team was asked to be certain about something that was never certain, and then blamed when the odds came due.
One date never removed the uncertainty. It only hid it.
The better question is not "When will it be finished?"
It is "What is the chance it will be finished by the date we need?"
Development can show that chance. The business must decide whether it is good enough.
A date used for internal planning can carry more risk than a date written into a client contract. A launch can move. A regulatory deadline cannot. Sometimes the right answer is a later date. Sometimes it is less scope. Sometimes the opportunity is worth the gamble. That is not a decision development should quietly make on behalf of the company.
Development should forecast. The business should commit.
Put the risk back into the conversation
I can hear the objection: if development only ever gives a chance, nobody can be held to anything anymore. The opposite is true. A forecast can be checked against what eventually happens. If dates described as highly likely keep failing, either the forecast is bad or the way the team works has changed, and both are visible. That is better accountability than arguing afterwards about who said what in a planning meeting.
Your current roadmap already contains risk. Your client promise already has a chance of being broken. Your launch date already has a chance of slipping.
You just cannot see it yet.
"Why is development so slow?" usually has a better answer than "the developers." Someone turned a probability into a promise, and the promise broke.
If you want the chance behind a date you're about to promise, I compute it from the records your team already keeps. No workshop, no new method, no new estimate.
See the chance behind your deadline
This analysis uses public records from three software projects: the Vera C. Rubin Observatory's Data Management software, MongoDB's Evergreen continuous-integration system, and Appcelerator Studio. The 14,210-task example and figures come from the observatory project. I repeated the completion-time comparison separately on two projects run by commercial software companies after reconstructing how each task moved from start to finish and separating finished tasks from cancelled ones. The conclusion held across all three. These are historical outcomes, not guaranteed future results.