The short answer
Quick answer: Software projects run late because they are mostly new work. If something had been built before, you would reuse it, so what remains is the part nobody has done in quite this way. You cannot estimate accurately what you do not yet understand. On top of that, people are systematically optimistic about their own plans, requirements change during the project, the last stages (integration, testing, edge cases) are larger than they look, and adding people to recover time often slows things down. Estimates then get treated as promises. The remedy is not better guessing but smaller pieces, ranges in place of single dates, early delivery, and flexible scope.
Also Read: Why Do Computers Need Both RAM and Storage? - How To's
Hofstadter's law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Douglas Hofstadter wrote the law in 1979, about the difficulty of programming computers to play chess. Its self-reference is the point: knowing you underestimate does not stop you underestimating.
The causes
1. The work is discovery
Building the hundredth identical house is predictable. Software is closer to designing the house, each time for a new site. The routine parts are already libraries and frameworks. What is left is the unknown, and you find its real shape only by doing it.
2. Unknown unknowns
You can add time for risks you can name. The delays come from the ones you cannot: an API that behaves differently from its documentation, a data migration with ten years of inconsistent records, a library bug, a performance problem that appears only with real data.
3. The planning fallacy
Psychologists Daniel Kahneman and Amos Tversky described the planning fallacy: people underestimate how long their own tasks will take, even when they know similar tasks overran before. We imagine the path where everything goes right, and estimate that.
Other biases add to it:
- Anchoring. The first number mentioned, however casual, becomes the reference.
- Pressure to please. A low estimate wins approval; an honest one may lose the project.
4. Estimates are lopsided
A task estimated at five days might finish in four. It might also take thirty. It cannot take minus twenty. The distribution has a long tail on the late side, so the average outcome is later than the most likely one. Add many tasks together and the overruns do not cancel out. They accumulate.
5. The last 10 percent
The so-called ninety-ninety rule:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
The working demo is the easy part. Then come error handling, edge cases, security, accessibility, performance, migration of old data, monitoring, documentation and deployment. "Works on my machine" and "running reliably in production" are far apart.
6. Scope creep
Requirements grow as people see the product take shape. Each addition is small and reasonable. The deadline rarely moves with them.
7. Brooks's law
In The Mythical Man-Month (1975), Fred Brooks, who managed the development of IBM's OS/360, observed:
Adding manpower to a late software project makes it later.
Two reasons:
- New people need training, which takes time from the people who are already productive.
- Communication grows faster than headcount. With
npeople there aren(n-1)/2possible pairs.
| Team size | Communication paths |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 10 | 45 |
| 20 | 190 |
| 50 | 1,225 |
His sharper version: nine women cannot make a baby in one month. Some work does not divide.
8. Dependencies and waiting
Much of a project's elapsed time is not work. It is waiting: for another team, a review, an approval, a vendor, a test environment. A task that takes two days of effort can take two weeks on the calendar.
9. Integration comes last
Parts built separately meet for the first time near the end, and that is when mismatched assumptions surface. Architecture affects this; see monolith vs microservices.
10. Existing debt
Building on a codebase full of shortcuts is slower than the plan assumed. See why technical debt isn't always bad.
11. Interruptions
Estimates assume uninterrupted time. Real weeks contain meetings, production incidents, support questions, holidays and illness. Few people get more than a few focused hours a day.
12. Vague goals
"Make it faster" and "improve the dashboard" cannot be estimated, because nobody has defined done. Unclear names for things make this worse; see why naming things is so hard.
Estimates, targets and commitments
Three different things are routinely confused.
| What it is | |
|---|---|
| Estimate | A forecast, with uncertainty |
| Target | What the business would like |
| Commitment | A promise to deliver |
Trouble starts when a rough guess given in a corridor is written into a plan as a commitment. Uncertainty is also widest at the very beginning, exactly when the date is usually fixed, and narrows only as work proceeds.
What actually helps
- Break work into small pieces. A task of a few days is estimable. A task of three months is a wish.
- Give ranges. "Six to ten weeks, most likely eight" is more honest and more useful than "eight weeks".
- Use your own history. How long did the last five similar features really take? This "outside view" beats reasoning from the task's details.
- Deliver in thin, working slices. Something usable early gives real feedback and real progress data. Automated builds and tests make this practical; see how CI/CD pipelines work.
- Tackle the riskiest part first. A short experiment (a "spike") turns an unknown into a known while there is still time to react.
- Fix the date or the scope, not both. If the date cannot move, decide in advance what can be cut.
- Leave explicit slack for the unexpected, and say that is what it is for.
- Limit work in progress. Finishing one thing beats half-finishing five.
- Re-estimate as you learn, and report slippage early. Bad news is cheapest on the day it is discovered.
- Keep teams small and stable.
- Define "done" to include testing, deployment and monitoring.
What does not help
- Crunch. Long hours raise output briefly, then defects and fatigue erase the gain.
- Adding people late. See Brooks.
- Punishing honest estimates, which teaches people to pad or to stay silent.
- Padding in secret. Work expands to fill the time, and trust erodes.
- Detailed plans for the far future, which give a false sense of certainty.
Does AI change this?
AI coding tools speed up writing code, sometimes a great deal. Writing code was rarely the bottleneck. Deciding what to build, agreeing on it, integrating it, verifying it and operating it take the bulk of the time, and those remain. Faster typing shortens some tasks; it does not repeal Hofstadter's law.
Frequently asked questions
Why are software estimates so inaccurate?
Because the work is largely new, the risks are unknown at the start, people are optimistic, and overruns are much larger than underruns.
What is Brooks's law?
The observation that adding people to a late software project delays it further, because of training time and increased communication.
What is the planning fallacy?
The tendency to underestimate the time needed for a task, even with knowledge that similar tasks took longer.
Should teams stop estimating?
Not entirely. Rough estimates help with priorities and budgets. Treat them as forecasts with ranges, and update them.
Conclusion
Lateness in software is not mainly a failure of discipline. It follows from doing uncertain work under optimistic assumptions and fixed dates. You cannot remove the uncertainty, but you can stop pretending it is absent: plan in small steps, forecast in ranges, deliver early, and keep the scope negotiable.
Related articles
- Why Technical Debt Isn't Always Bad
- Why Is Naming Things So Hard in Programming?
- How CI/CD Pipelines Ship Code Automatically
- Monolith vs Microservices: Why Companies Switch (Both Ways)
Sources and further reading
