Why your software estimates are never right

2025-02-25

I preemptively apologise for the title - this is a huge topic, and the title is only a small part of it. This blog is ultimately more about how estimates in software are part of an ecosystem of trade-offs which make them much less useful than you might intuitively expect.

Misuse of this unintuitive tool has lead an uncountable number of people to make bad decisions. That in turn has prematurely wrecked an uncountable number of software projects. Don’t let yours be next!

Topics

Estimates are in the middle of a Monkeys Paw Knot (My favourite knot) of related issues. We’re going to go over them, and the rough order is as follows:

There’s a lot of interconnections between these topics, which is what makes this topic so unintuitive. They somewhat need to be understood as a whole chunk of concepts resting on each other like one of those popsicle stick shapes that is held together by it’s own tension.

Deadlines

I want to establish a taxonomy before we get further into this topic. Deadlines are intimately associated with estimates, due to how the existence of estimates often causes deadlines to manifest. Many people cannot conceive of work without deadlines, and go so far as to create deadlines where none exist. Those people often proceed to decorate their deadlines with little festive problems, an unhelpful behaviour pattern.

Real deadlines

A Real deadline is a deadline that is created by an outside constraint of reality, that has tangible results if it is missed. In my career, they have been surprisingly uncommon, but your mileage may vary.

An example Real deadline might be shipping this years Switch tie-in game for the latest Disney release. The kids will only be excited about Frozen 17 (the IP you licensed) this year. Next year, when Moana 5 comes out, they’ll forget all about it. The movie is coming out in September and kids usually don’t buy their own games, so 90% of your sales ever are going to happen in the 4 weeks leading up to Christmas. Factoring in manufacturing and shipping, if you’re making physical cartridges, you’ll find you’d better ship by something like end of October at the latest or you’re gonna get almost nothing for your investment.

Real deadlines matter. However, they also beg discussion about when to cut investment, which we will discuss later.

Fake deadlines

Fake deadlines are deadlines for which there are no externally inflicted consequences if they are missed. Bad managers sometimes invent Fake deadlines to “keep the team motivated”[1] and chastise teams that fail to meet them. However, they can also happen for less stupid reasons.

“We must ship the product by June 12th!”
“Why, what happens on June 12th?”
“It’s the companies 10th anniversary!”

If the product needs another two weeks of time to avoid becoming a PR disaster, perhaps it might be OK to not ship on the 12th?

This is all about project value creation. If you miss Real deadlines, the project will no longer create value when finally delivered. The defining attribute of Fake deadlines is that missing them doesn’t change the value created by the project upon completion at all.

Fake deadlines are a distraction for your team, and attempting to meet them burns capacity in ways that can cause serious problems, as we shall discuss when we get to queuing theory. Attempting to meet other forms of deadline also burns capacity, but when dealing with Fake deadlines, you may be burning capacity for no meaningful reason.

Ascended fake deadlines

Ascended fake deadlines are Fake deadlines that have become real, or at least less fake, because the company voluntarily made them so. This is the dangerous one for estimates.

Someone asks for a rough estimate of how long a project will take, a hip-shot is made. That goes through a series of emails, and somehow - almost magically - 8 months later there’s a contract between your company and an entire government that says that’s the delivery date. Missing the delivery date triggers a $100,000 fine, plus another one every 6 months thereafter. This will severely cut into the profitability of the contract, maybe even turning it negative.

This is an Ascended fake deadline. The company voluntarily turned a rough estimate into a fineable contractual promise. You’d better hope it was a good estimate.

Except, oh dear, the title of this blog.

There are other ways this can happen. Your company might have a media embargo set to expire at a certain time and be racing towards final patches, for example. This is still an Ascended fake deadline, because you got to set the embargo end date.

Estimates

Now that we’ve defined the various forms of deadline, we must talk about estimates. I want to explain why estimates are so fuzzy in software. Once we’ve done that, we’ll pull our two topics together and talk about how estimates interact with deadlines.

How long is a piece of string?

One of the fundamental problems with estimating how long a software project will take is in isolating where the finish line actually lies. In general, software projects are never done until they are dead and buried. About 70% of the cost of a project is maintenance. So at what point do people declare a deadline or estimate met, and pop the champagne?

My personal experience is that internally-driven projects are a process of discovery where the finish line is reached once all major stakeholders are happy. Stakeholders can never tell you what will make them happy, only what is currently making them sad. The project starts with a vague list of goals that get turned into tickets. Over the course of the project, the stakeholders learn many things about how the world is more complex than they guessed, and the goals and tickets flex and change to match this increased understanding.

External projects, by contrast, may have an exhaustive pre-created list of requirements. These external requirements are no better informed than internal ones, merely more exhaustively enumerated. The tricky part is who gets to decide when they are met. If the customer gets to decide, your sales department has failed you so badly it borders on active sabotage. The customer will redefine the meaning of requirements on a daily basis. Even if the customer does not get to decide unilaterally, these requirements will be reinterpreted to fit whatever situation the project finds itself in. Think about the way old laws get interpreted through the lens of new scenarios.

In both cases, you can start with a list of written requirements if it makes you feel better, but no plan survives contact with the enemy. Features will be added, removed and re-prioritised as the organisation learns about the specifics of the domain. With the finish line little more than a mirage on the horizon, it’s not surprising that our whole industry struggles to accurately predict how long it will take to get there.

Bridges vs tunnels

Most other industries are very specialised, and still do estimates with more rigour than software. If you ask a bridge firm how much a bridge costs, they’re gonna reply:

“Depends on the bridge. We need a proposed site, a brief about the project, and a budget to conduct research. We’ll get back to you in 3-5 months”.

No one ever gives software teams 3-5 months to conduct ground surveys. I’m not saying it would make sense to do so (code is much more malleable than poured cement), but you can’t half-arse the ground survey and then be surprised if your tunnel hits an aquifer.

Making matters worse, software is still a new and cross discipline industry. Software engineers, over the course of their careers, rarely make the exact same thing twice. Yeah, you’re working with steel, concrete and groundworks every time, but a bridge isn’t a tunnel and an online store for shipping alcohol isn’t a video subscription service.

It’s important to remember that if what you’re doing is non-trivial, it’s likely the first time your engineers have made that exact thing. Depending on what you’re doing, it might be radically different from anything they have ever done. I mean, your company considers innovation a core value, right?

Your engineers might know some of the pitfalls from working in related areas with similar tools, but this bridge you’re planning is still unique. If it wasn’t, you’d be buying it off the shelf.

Social pressure

I’ll keep this short because others have written better on it. Your team is under pressure (whether you realise it or not) to give estimates that present them as speedy, go-getting doers. More senior engineers who feel more secure in their career may start employing the Scotty method in response. This isn’t malicious, they are trying create more slack in the schedule (see queue theory below) to compensate for the short estimates they know their less experienced colleagues are giving. Engineers are not the only ones who do this, either. Sometimes, the most important job of a producer, being between the teams and management, is to lie in both directions so that they can produce time out of thin air when needed.

None of these behaviours make estimates more accurate, quite the opposite in fact. The latter two are forms of damage control to prevent inaccurate estimates from causing problems, but they don’t improve estimates, they simply de-risk them.

Oh crap, here comes reality

OK, so we’ve established that deadlines exist and some of them even matter, and we’ve established why it might be difficult for your engineers, even given adequate time, to give magic crystal ball predictions of how long it will take to deliver the project.

As you work on the project and learn more about it, your estimates will get better. Partly because work is getting crossed off, and partly because you learn the domain as you go.

So what happens when you start to realise you’re three quarters of the way through the time to the deadline and only half way through the project?

Moving the deadline

I’m not going to dwell too much here. If it’s a Fake deadline, you can just move it. Maybe ask yourself why that deadline is even there. If it’s an Ascended fake deadline you might have some wiggle room but that’s contextual. You usually can’t move Real deadlines.

Cutting scope, and MVP’s

I think most people who are reading this blog will already have thought of this option. Just cut features until you can make it!

This is totally an option, a good one. It’s also why you should avoid minimum viable products at all costs[2]. The problem with MVP’s is that, by definition, if you remove anything from them they are now no longer viable.

This is important to understand. I have worked for a company that routinely chose to cut features from MVP’s to meet Fake deadlines. They were perplexed that their non-viable projects kept failing to meet expectations. If you don’t make sure your project has some technically-optional nice-to-have features in the project goals from the start, you have nothing to cut when you find yourself here.

If you make it on schedule, your project will be better for it. If you run behind, you can cut them. Make sure you have material to work with!

Ending the project

If you have nothing to cut, then there is only one other discussion to have:

Is it time to end the project?

This is where it gets interesting. If you have a Real deadline, people will engage with you on this topic.

Think about it. If the company is on a track to burn $100,000 of salary every month for the next 10 months only to miss the shipping date and lose 90% of it’s revenue anyway, people will be very interested in finding other uses for that million dollars.

Your company may also entertain the option for an Ascended fake deadline. What is the sting fee for pulling out of the contract? How does that compare with the expected profitability? Can we renegotiate?

Obviously, this is all contextual. Sometimes, the company is truly stuck. However, if you raise the possibility and no one seems interested in considering it, you are probably dealing with a Fake deadline. Everyone else intuits that missing the deadline doesn’t really change the value the project will create. Work hard to stop the Fake deadline from Ascending, since you already know it’s not likely to be met.

Nothing

Often, the company will choose to do nothing to address the fact that a deadline appears to be incompatible with newer, more informed estimates.

Implicitly, this is a request from the company for teams to just hurry up. Attempting to comply might be fine if it only happens over a week or two (crunch, not that I recommend it as a strategy), but longer term attempts to comply (permacrunch) brings us to queue theory.

Queue theory

Imagine you have a conveyor belt. Boxes are being added to it at a regular rate, 4 per minute. The conveyor can have 8 boxes on it at any time before it is full, at which point boxes are dropped on the floor where they will be lost and never seen again.

┌────┬────┬────┬────┬────┬────┬────┬─────┐
│    │    │    │    │    │    │    │     │
│    │    │    │    │    │    │    │     │
@────┴────┴────┴────┴────┴────┴────┴─────@
@────────────────────────────────────────@

An 8 capacity conveyor belt

Lets say every person you hire can move 1 box per minute from the conveyor. How much workforce should you have to handle the conveyor correctly, without overspending?

                       ▼    ▼    ▼    ▼
                     ┌───┐┌───┐┌───┐┌───┐
┌────┬────┬────┬────┬┤   ││   ││   ││   ├┐
│    │    │    │    ││   ││   ││   ││   ││
│    │    │    │    │└───┘└───┘└───┘└───┘│
@────┴────┴────┴────┴────────────────────@
@────────────────────────────────────────@

Every minute, 4 boxes arrive

Four, right? That matches the throughput, surely that’s obvious?

                     ┌───┐┌───┐┌───┐┌───┐
┌────┬────┬────┬────┬┤   ││   ││   ││   ├┐
│    │    │    │    ││   ││   ││   ││   ││
│    │    │    │    │└───┘└───┘└───┘└───┘│
@────┴────┴────┴────┴────────────────────@
@────────────────────────────────────────@
                       ▲    ▲    ▲    ▲   
                      Tom  Liz  Ari  Ann

4 boxes, 4 workers. Flawless! one minute later…

┌────┬────┬────┬────┬────┬────┬────┬─────┐
│    │    │    │    │    │    │    │     │
│    │    │    │    │    │    │    │     │
@────┴────┴────┴────┴────┴────┴────┴─────@
@────────────────────────────────────────@
                     ┌───┐┌───┐┌───┐┌───┐
                     │ ▲ ││ ▲ ││ ▲ ││ ▲ │
                     │Tom││Liz││Ari││Ann│
                     └───┘└───┘└───┘└───┘

They’ve cleared the belt just in time for the next batch, excellent!

Here’s the problem with that. You hire exactly 4 people, so you’re matching the throughput 1:1. Then one day, someone adds a 5th box. Why? Who knows. Life is complex. Maybe the CEO had a great idea, packaged it up in a box and put it on the conveyor personally. There’s still 4 regular boxes being added per minute, but now there’s 5 boxes on the belt at the peak of the cycle.

                  ▼    ▼    ▼    ▼    ▼
                ┌───┐┌───┐┌───┐┌───┐┌───┐
┌────┬────┬────┐│CEO││   ││   ││   ││   ├┐
│    │    │    ││REQ││   ││   ││   ││   ││
│    │    │    │└───┘└───┘└───┘└───┘└───┘│
@────┴────┴────┴─────────────────────────@
@────────────────────────────────────────@
                       ▲    ▲    ▲    ▲   
                      Tom  Liz  Ari  Ann

Management has a special request

                                    ┌───┐
┌────┬────┬────┬────┬────┬────┬────┐│CEO│┐
│    │    │    │    │    │    │    ││REQ││
│    │    │    │    │    │    │    │└───┘│
@────┴────┴────┴────┴────┴────┴────┴─────@
@────────────────────────────────────────@
                     ┌───┐┌───┐┌───┐┌───┐
                     │Tom││Liz││Ari││Ann│
                     └───┘└───┘└───┘└───┘

Everyone is handling a box this minute, but there’s one box left over

The workers then remove 4, but there’s 1 left at the end of every cycle. There will always be 1 left at the end of every cycle now, because your work rate has no slack time in it.

                  ▼    ▼    ▼    ▼
                ┌───┐┌───┐┌───┐┌───┐┌───┐
┌────┬────┬────┐│   ││   ││   ││   ││CEO│┐
│    │    │    ││   ││   ││   ││   ││REQ││
│    │    │    │└───┘└───┘└───┘└───┘└───┘│
@────┴────┴────┴─────────────────────────@
@────────────────────────────────────────@
                       ▲    ▲    ▲    ▲   
                      Tom  Liz  Ari  Ann  

                                    ┌───┐
┌────┬────┬────┬────┬────┬────┬────┐│   │┐
│    │    │    │    │    │    │    ││   ││
│    │    │    │    │    │    │    │└───┘│
@────┴────┴────┴────┴────┴────┴────┴─────@
@────────────────────────────────────────@
                     ┌───┐┌───┐┌───┐┌───┐
                     │Tom││Liz││Ari││Ann│
                     └───┘└───┘└───┘└───┘

This situation is going to happen every cycle now, it is unrecoverable unless something changes

A few months later, something breaks. Someone picks up the shards of the broken thing, shoves them in a box, and throws them on the conveyor. Now there’s 2 things on the conveyor every cycle. Not the same two things, everything’s still being processed reasonably fast, but now there’s always 2 extra boxes left at the end of every minute.

             ▼    ▼    ▼    ▼    ▼
           ┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
┌────┬────┐│   ││   ││   ││   ││EMR││   │┐
│    │    ││   ││   ││   ││   ││GCY││   ││
│    │    │└───┘└───┘└───┘└───┘└───┘└───┘│
@────┴────┴──────────────────────────────@
@────────────────────────────────────────@
                       ▲    ▲    ▲    ▲   
                      Tom  Liz  Ari  Ann  

                               ┌───┐┌───┐
┌────┬────┬────┬────┬────┬────┐│   ││   │┐
│    │    │    │    │    │    ││   ││   ││
│    │    │    │    │    │    │└───┘└───┘│
@────┴────┴────┴────┴────┴────┴──────────@
@────────────────────────────────────────@
                     ┌───┐┌───┐┌───┐┌───┐
                     │ ▲ ││ ▲ ││ ▲ ││ ▲ │
                     │Tom││Liz││Ari││Ann│
                     └───┘└───┘└───┘└───┘

Nothing has been changed, and now the situation is escalating

Eventually, 2 more unexpected boxes will hit the conveyor, and now when the 4 standard boxes are added every minute, it temporarily leaves the queue full. It now takes a full minute for the newly added boxes to be touched at all. The whole conveyor team is always a full cycle behind.

   ▼    ▼    ▼    ▼
 ┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
┌┤   ││   ││   ││   ││   ││   ││   ││   │┐
││   ││   ││   ││   ││   ││   ││   ││   ││
│└───┘└───┘└───┘└───┘└───┘└───┘└───┘└───┘│
@────────────────────────────────────────@
@────────────────────────────────────────@
                       ▲    ▲    ▲    ▲   
                      Tom  Liz  Ari  Ann  

                     ┌───┐┌───┐┌───┐┌───┐
┌────┬────┬────┬────┐│   ││   ││   ││   ├┐
│    │    │    │    ││   ││   ││   ││   ││
│    │    │    │    │└───┘└───┘└───┘└───┘│
@────┴────┴────┴────┴────────────────────@
@────────────────────────────────────────@
                     ┌───┐┌───┐┌───┐┌───┐
                     │ ▲ ││ ▲ ││ ▲ ││ ▲ │
                     │Tom││Liz││Ari││Ann│
                     └───┘└───┘└───┘└───┘

The team is now a full development cycle behind

Finally, a 5th unexpected event happens. Now there’s 5 boxes on the queue. The loader goes to add the 4 standard boxes on. Oh no, that’s 9 boxes for an 8 box conveyor! One falls on the ground, lost forever.

                        ▼
                      ┌───┐┌───┐┌───┐┌───┐┌───┐
      ┌────┬────┬────┬┤LAW││   ││   ││   ││   │┐
      │    │    │    ││SÜT││   ││   ││   ││   ││
      │    │    │    │└───┘└───┘└───┘└───┘└───┘│
      @────┴────┴────┴─────────────────────────@
      @────────────────────────────────────────@
                             ▲    ▲    ▲    ▲   
                            Tom  Liz  Ari  Ann  


   ▼     ▼    ▼    ▼                            
 ┌───┐ ┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐
 │   │┌┤   ││   ││   ││LAW││   ││   ││   ││   │┐
 │   │││   ││   ││   ││SÜT││   ││   ││   ││   ││
 └───┘│└───┘└───┘└───┘└───┘└───┘└───┘└───┘└───┘│
      @────────────────────────────────────────@
      @────────────────────────────────────────@
                             ▲    ▲    ▲    ▲   
                            Tom  Liz  Ari  Ann  



                            ┌───┐┌───┐┌───┐┌───┐
       ┌────┬────┬────┬────┐│   ││   ││   ││LAW├┐
       │    │    │    │    ││   ││   ││   ││SÜT││
       │    │    │    │    │└───┘└───┘└───┘└───┘│
       @────┴────┴────┴────┴────────────────────@
       @────────────────────────────────────────@
┌─────                      ┌───┐┌───┐┌───┐┌───┐
│$#&#$                      │ ▲ ││ ▲ ││ ▲ ││ ▲ │
│$&%$%%$&                   │Tom││Liz││Ari││Ann│
└───────                    └───┘└───┘└───┘└───┘

The queue is full, a box has been dropped. Hopefully it wasn’t expensive?
Your team probably didn’t notice it was dropped, they’re busy as hell and have been for several minutes now

Your engineering team are the workers. The regular tasks are standard things your business must do. Updating infrastructure, keeping up with changes to your vendors APIs, the steady churn of feature work that keeps the company competitive. The unexpected boxes are things like sudden outages caused by tech debt that has come home to roost, or directives from management.

Trying to run your team at 100% is unwise. You need them to have slack time. Imagine if you had a 5th worker. Yeah, in a normal cycle that means 1 person gets to slack off, but when that unexpected 5th box shows up, it’ll get consumed immediately. Even if 7 boxes get dropped off at once, your 5th worker will chip away at them over 3 cycles, and eventually the queue will be clear again. This is the value of slack time in your schedule. Slack time absorbs unexpected delays in the same way that leaving extra space between your car and the vehicle ahead absorbs the fluctuations that otherwise turn into phantom traffic jams.

In reality, you don’t have 4 workers running at 100% and 1 worker doing nothing, instead your team is working at 80% capacity, which is healthy. They can use the spare time to plan ahead, upskill themselves, and perform non-critical but still valuable maintenance. When that 5th box arrives, they’ll handle it in stride so effectively you might not even realise something unexpected happened, they just won’t bother to tell you.

If you ask them to run at 100% to meet a deadline, that can work in the short term as a temporary thing. But if you do it next quarter as well, and the quarter after, then those unexpected boxes will build up. Before you realise it, you’re in permacrunch. You’re 2 months behind at all times, and it feels like you can’t stop now. Maybe if you can just keep the pace up a little longer, you’ll dig your way out?

You won’t though, because the boxes are just going to keep coming. You’ll have to hire more people, and that’ll kill your team performance in the short term because of Brooks' law, so you’ll fall even further behind before you can start catching up. Digging out of permacrunch takes years, always.

It’s around this point that you’ll start to realise that your conveyor belt also has a maximum capacity. It might not have been clear how a software project can have a maximum capacity, but I can promise that yours does have one. Everyone’s does.

In most companies, it’s called the “Jira backlog”. A digital oubliette into which tickets fall, never to be seen again. The exact ways that goes wrong are perhaps a topic best saved for another (probably smaller) blog, but once you’ve got tickets going into an expanding but never curated dumping bucket, that’s boxes falling off your conveyor.

It’s also around this point that your employees will start leaving with minimal or no notice, because you are abusing them. Only the most desperate of employees will choose to endure long term permacrunch.

Final thoughts

What I have described here is a common pathology. It starts with “Hey, can we grab a quick estimate?”, turns into an unnecessary deadline, forces crunch, and finally drowns a team. It’s not the only way estimates can work out, but every time you ask for an estimate, this pathology has a chance to arise. Like surgery, every estimate carries risk. Most workplaces have never heard of of an autoclave and just kind of go for it.

I don’t have magic solutions for you on what to use instead of estimates. Joel Spolskey has an interesting idea. I don’t endorse it, but it stands nicely as an example that there might be other options than insisting on estimates anyway and then being surprised when they don’t work properly again.

Client’s want ‘em because what client wouldn’t want perfect certainty at a fixed cost? That’s why your manager wants them too.

Reality is more complex than that. Reality will happen to every project you are involved in, no matter how much you would prefer it not to. People will get sick, vendors will ignore your emails for weeks, things will go out of stock and hardware will die.

The holy trinity is:

In the big leagues (military submarines, hydroelectric dams), serious clients expect to be able to have only one of these at a time, and may be suspicious of your bid if you offer to give them two or more in the same contract.

Anyone who has lived in a city has seen a major building project get put on indefinite hiatus for years because it has started running over budget. When building a new train station on municipal funds, perhaps if the cost of steel goes up it turns out that the timeline is flexible and the project can wait until economic conditions improve. Sure, the mayor would like the station to be ready by next election, but bankrupting the city is a much worse look.

In the medium leagues of normal business and the small leagues of internal company decision making, people will take you up on your foolish guarantees to do more than one of the trinity and then fleece you or hang you with your own promises as they desire.

In most companies, your team’s salary is considered a fixed cost, and you cannot request more people for larger projects. However, you are also usually asked for fixed time estimates. As if that wasn’t enough, your management team will often enthusiastically tell you they only want an MVP, thinking they are being savvy. In reality, they are sabotaging you. I hope by now it is clear why I think these things are fundamentally incompatible.

This problem is never going to go away, but at least now you understand it a little better. Try to keep your team at 80%, and work hard to stop people from making or Ascending Fake deadlines.

Good luck.

[1] Dear managers, please seek a new career if you do this
[2] This advice does not apply to startups on limited runway, but most projects aren’t under those kinds of constraints.