For 12 years, I blogged and wrote a whole bunch. For the past year and a half, I’ve let myself be pulled away from so many of the things that make me me… including writing. Today I heard one of the best anecdotes ever, and it’s the spark that will be pulling me back in. (Thanks, John.)

So here it is! It has to do with software estimation. Not only is it difficult to accurately estimate how long it’s going to take someone to do a programming (or similarly technical) task, the act of estimating often does not add any value at all. Estimation is a bad thing, especially if you’re trying to be Agile.

(And if you’re in a client/contractor relationship, you’ll have discovered that estimates are the lifeblood of the relationship, even as they drain all the life and all the blood out of the relationship, slowly and deliberately.)

Sometimes I get caught asking engineers for estimates even when the task we’re embarking on is new, unknown, uncertain, and requiring lots of learning and exploration and discovery. I should know better. But I cave, because the concept of the software estimate is so enticing: with a good estimate, I’ll know exactly how much time someone will need to spend working on a task that’s still kind of nebulous and mostly unknown. (That was a joke.)

My friend John shared the best anecdote ever today about why software estimation is so frustrating (liberally embellished):

Imagine that you’re standing on a hill looking down at a labyrinth, or a corn maze. It’s reasonably small… you can see that the corn maze is definitely doable, you can see a couple paths in and out, and the entire maze is a similar size to other mazes you’ve successfully found your way out of. So you’re pretty sure once you get to the entrance, you’ll find your way out.

But there’s no way you can say exactly how long it will take you to escape. Maybe you’ll run right through from start to finish, and it will be smooth. Maybe you’ll get stuck in the beginning, and spend a long time before winding your way out. Maybe you’ll run right close to the end, but have no idea you’re a few feet away from the exit, and you’ll get stuck there for a while.

And maybe you’ll make it halfway through, get lost, go in circles, and eventually just die in the maze.

Problem is, I can tell you how long it’s taken me to get across comparable mazes, but I have no way of knowing how long it will take me to escape from this maze, and just having another engineer in the maze to pair with me and see things I’m maybe not seeing is no guarantee at all that either of us will get out of there. Statistically, we’ll probably make it out and survive, but the estimate I give you is just a guess.

Unfortunately, it’s a guess that’s going to make a lot of people unhappy, no matter what. Because even if I make it out of the maze fast this time, then they’ll expect that I’ll zoom through the next maze.

– John

One response to “Why Software Estimation is (Often) Useless”

  1. Dave Avatar
    Dave

    The problem with software estimates is that nobody actually treats them like estimates. You may use the word “estimate” your client hears the word “commitment”. The reason for that is that business run on commitments. They have to. Business is an inherently collaborative endeavor. No business runs in complete isolation and they have no choice but to rely on the people they do business with to come through for them.

    If you were getting your house ready to put on the market and the plumber told you “well, you have a leak and there’s no way I can know how much it’s going to cost to fix until I completely finish the job. Could be $1,000 could be $30,000. Maybe I’ll get almost all the way done and realize it’s impossible to fix. Anyhoo I’ll let you know when we’re done if we ever finish.” You’d find another plumber. The hard fact is that businesses have a legitimate and just need for accurate estimates, but it’s not really possible for us as software developers to provide them with any consistency for anything but the most simple of software projects. Software is simply far too complex for accurate estimation.

    So essentially businesses need something that we can’t really give them. That’s why the software estimation problem hasn’t been solved in the last 75 of the world making software and it probably won’t be solved until something pretty drastic changes about how software is created or how businesses are run (cue AI to take all our jobs away from us).

Leave a Reply

I’m Nicole

Since 2008, I’ve been sharing insights and expertise on Digital Transformation & Data Science for Performance Excellence here. As a CxO, I’ve helped orgs build empowered teams, robust programs, and elegant strategies bridging data, analytics, and artificial intelligence (AI)/machine learning (ML)… while building models in R and Python on the side. In 2025, I help leaders drive Quality-Driven Data & AI Strategies and navigate the complex market of data/AI vendors & professional services. Need help sifting through it all? Reach out to inquire – check out my new book that reveal the one thing EVERY organization has been neglecting – Data, Strategy, Culture & Power.

More About Me or HIRE ME OR MY PEOPLE

Let’s connect