Why software estimates are always wrong, and how to get one you can plan with

The conversation goes like this. The manager asks for a change to the order screen: a new field, a new rule for discounts, a small report. The developer thinks for a moment and says: “About two weeks.” Two months later it is still not finished, and the manager is wondering whether the developer was lying, lazy, or simply bad at their job.

Usually none of the three. The estimate was probably honest for the work as it was described on day one. The problem is that the work on day one and the work that was actually delivered were not the same work, and that the two weeks assumed two weeks of uninterrupted time that never existed.

This article is for the owner, the CEO or the head of operations who has to plan around software and keeps getting surprised. It covers why estimates miss, what really happens to the time, and how to ask for an estimate you can actually plan with.

Estimates start wide, and that is normal

Steve McConnell, who has written the standard book on software estimation, describes the cone of uncertainty. At the very beginning of a piece of work, when it is just an idea, an estimate can be off by a factor of four in either direction. Two weeks could really be half a week, or eight weeks. As the work is defined, designed and started, the range narrows.

Stage	Realistic range for “two weeks”
Idea, described in one sentence	0.5 to 8 weeks
Agreed what it should do	1 to 4 weeks
Requirements written and checked	1.3 to 3 weeks
Design done, work started	1.6 to 2.5 weeks

McConnell calls this the best case. It narrows only when someone actually makes the decisions that remove the uncertainty. Time passing does not narrow it by itself.

That is the first reason for the surprise: a single number given on day one, for a one-sentence request, is the least reliable estimate there will ever be. Most “two weeks” are given exactly at that point.

Where the time actually goes

Even when the estimate for writing the code is right, the code is only part of the work. A realistic breakdown of a “two-week” change in an established business application:

Work	Usually counted in the estimate?	Typical share
Writing the new code	Yes	40 %
Understanding the existing code it touches	Partly	15 %
Tests, and fixing what the tests find	Often not	15 %
Code review and changes after review	Rarely	10 %
Release, configuration, migration of data	Rarely	10 %
Questions, clarifications, waiting for answers	Never	10 %

The shares are illustrative, not measured, but anyone who has delivered software will recognise them. If the developer estimated only the first line, the honest total was closer to four or five weeks before anything went wrong. Older systems make the second line much bigger, as our article on technical debt and slow development explains.

How two weeks become two months

The biggest cause is rarely the estimate. It is what happens after it. An example, invented but typical:

1. Week 1Work starts as agreed
2. Week 2"Can it also handle returns?"
3. Week 3Urgent production issue, three days lost
4. Week 4A different project becomes top priority
5. Week 6Back on it, half of it needs re-learning
6. Week 7The discount rule changes after a demo
7. Week 9Finally delivered

Nobody did anything wrong in a dramatic way. Every single request was reasonable. Together, they turned a two-week job into a nine-week one. What each of them really cost:

What was asked	What it sounds like	What it really costs
“Can it also handle returns?”	One more case	New rules, new tests, often a redesign of what was already built
An urgent issue in production	Three days	Three days, plus the time to get back into the work
“Put this on hold, the other project is more urgent”	A pause	Re-learning the work later, and the risk that the code underneath changed
A change after a demo	A small correction	Undoing and redoing part of what is finished
“Just a quick question” several times a day	Nothing	Broken concentration, every time

The context switches deserve a number. The software author Gerald Weinberg proposed a rule of thumb: every additional project a person works on in parallel costs about 20 % of their time just in switching. A developer split between two projects does not give each one half of their week, but closer to 40 %, and the remaining 20 % is lost in between.

Why pressure does not help

When deadlines slip, the natural reaction is pressure: a firm date, a daily status meeting, a reminder that the customer is waiting. It usually makes things worse.

• Under pressure, estimates get shorter, not better. People give the number that ends the meeting, not the number they believe.
• Tests and review are the first to go. The deadline is met, the bugs arrive a week later, and fixing them costs more than the time saved.
• Status meetings are interruptions too. A daily check-in on a late task takes time away from the task.
• Good developers notice. Constant deadline pressure on top of constant priority changes is one of the reasons senior developers leave.

How to ask for an estimate you can plan with

You cannot make software estimation precise. You can make it useful.

1. Ask for a range, not a number. “Between two and four weeks” carries more information than “three weeks”. If the range is very wide, that is useful information too: the work is not yet understood.
2. Ask what would make it longer. “What could turn this into six weeks?” The answer shows you the risks, and often a decision you can make now to remove one.
3. Split the work. A big piece of work estimated as a whole is a guess. The same work split into pieces of a few days each, each delivered and shown separately, is a plan. A clear software requirements document helps a lot here.
4. Let the estimate include everything. Ask explicitly: does this include tests, review, release and data migration? If not, add them.
5. Re-estimate when something changes. A new requirement is a new estimate, not a footnote to the old one.

What you can do as a manager

Most of the time lost in the example above was not in the developer’s hands. These are in yours:

• One channel for new requests. Ideas, bugs and changes go to one place, not straight to whichever developer is nearest.
• Priorities that hold for at least two weeks. Change them when you must, but not every few days. A plan that lasts two weeks is worth more than a perfect one that lasts two days.
• New ideas go into the next round. “Can it also handle returns?” is a good question, and the answer is: yes, in the next piece of work, with its own estimate.
• Protect focus time. Fewer meetings, fewer quick questions, and one person who handles urgent production issues, so not everyone is interrupted.
• Look at the trend, not one miss. If a team is consistently 50 % over, plan with 1.5 times their estimates and work on the causes. That is more honest than pretending the next one will be different.

When the work goes to an external partner, the same logic applies to the contract. Our article on fixed price or time and materials explains why a fixed price does not remove this uncertainty, it only moves it into the price.

Questions we hear most

Why can’t a developer just give an exact deadline?

Because at the start, nobody knows exactly what the work will involve, including the person asking for it. Details appear as the work is done. An exact date at the start is a promise, not an estimate, and promises made under uncertainty tend to be broken.

Should we add a buffer to every estimate?

A hidden buffer that everyone knows about tends to get used up anyway. It works better to ask for a range, plan around the upper half of it for things that really matter, and keep the reasons for the range visible.

Our team is always late. Are they just slow?

Possibly, but check the other causes first: how often priorities change, how many projects each person works on, how many interruptions there are, and how old and tangled the code is. In our experience, those explain most of the delay.

Do estimation techniques like story points help?

They can help a team estimate consistently and spot its own patterns. They do not help when the work keeps changing underneath the estimate. Fix the flow of work first, the technique second.

How we work

ProCoding is a .NET studio in Split, Croatia. We build and maintain business applications, and a large part of doing that well is how work is planned: small pieces that can be shown every week or two, estimates as ranges with the risks named, and changes that go into the next round instead of disrupting the current one. On your own project, with your team, or with a freelance .NET developer inside your team. The first step is a free 30-minute call.

Sources

• The Cone of Uncertainty, Steve McConnell, Construx
• The Multi-Tasking Myth, Jeff Atwood, on Gerald Weinberg’s rule of thumb for switching between projects