Estimating: Stop Trying Harder

(Note: Lightly edited and adapted from a twitter thread, where I’m @GeePawHill. Noobs be advised, I speak freely there.)

Accuracy in estimating software development times is a powerful example of forty years of “try harder” not producing any positive results.

Now, given some small change X and some substantial knowledge of the current state of my software, I can usefully estimate short-term work, from a few minutes up to a 50% hit-rate around about a week. This is because I have been a successful independent programmer for 35 years.

Without making any ridiculous boasts about my mad geek chops, I can still say this: I am good at programming, and very experienced. I am telling you that my estimating skill starts having more misses than hits in units measured in single-digit days. And that is when I have strong knowledge of the existing code base.

A week. Maybe two.

I Have Seen This

VLCAs[1] routinely spend weeks estimating things that are months away. And they do it over and over again in spite of the lack of consistent value.

Companies spend millions of dollars on this waste, then won’t buy hardware for their teams, even teams that are currently winning. (I am not exaggerating for effect. I know I often do, but I am not doing so now. Sometimes I say such strange but true things that I have to make this clear.)

The dollar waste is truly staggering. And dollars don’t begin to capture the cost in team stress.

It is to laugh. Or cry. I can never quite decide.

This Theory Is Bunkum

They patiently explain to me, as if I were a goodhearted but somewhat simple neophyte, the theory of how their planning works. It’s centered around the sophisticated concept of something called “addition of numbers”.

Sadly, the numbers are a) made from whole cloth, b) made entirely without consideration of each other, and c) not able to take into account even minor changes in market.

Why are people so resistant to the dramatic evidence that comes from every side of our trade? I think it’s a combination of confirmation bias and third-rate thinking.

People have any two successes in a row and they think they’ve discovered a method. Sometimes it’s just one partial success. When they have three in a row, they give it a catchy acronym and pretend it’s a system others should pay to learn.

A Cheap Experiment And A Proposal

Flip a coin and see how long it takes you to get 3 heads in a row.

That’s what a 50% success rate looks like.

When it happens, do you believe you have invented a new technique for coin-flipping, require it of all future coin-flippers, and start buying up clever domain names to advertise it? If so, I have any number of wagers I’d like to make with you. I will travel, if the stakes are sufficient.

For a small handling fee, I’ll even procure your domain names for you.

What Do We Do Next?

Meanwhile, in that same part of the forest, VLCAs constantly ignore the far more urgent question: what is the next most important change we should make?

Not only is “what’s next” more important than “where’s it end when”, it’s also vastly easier to determine. No one can describe the state of their software a year from now. Everyone has an idea about the next important small bit.

Now, given that we have failed at this accurate-long-term-planning thing ten thousand times, maybe we need to rearrange things so we don’t have to do it at all any more.

You can know where you are now and where you will be tomorrow. I mean, literally, “tomorrow”, not metaphorically.

Try Different

It seems strange to have to coach giving up, but that’s what I do. Please give up trying to predict the state of your software a quarter from now, because it can not be done for less money and time than spending a quarter getting there.

They say, “If we don’t know the future we don’t know the optimal way to get there.”

I say, “You can’t know the future and you can’t know the optimal way to get there until it is past.”

Change your business model so you don’t have to reliably predict the state of your software more than a month ahead. There are myriad ways to make this happen.

Or continue to spend hundreds of millions of dollars every year to not get what you want, in service to some over-simple theory, in the absence of consistent real data that the theory is valid.

Optimize Knowing What To Do Now

[1] VLCA is a GeePaw-ism: It means Very Large Corporation of America, an allusion to the Monty Python short called “The Crimson Permanent Assurance”, typically but not universally shown as the opening short film before “The Meaning Of Life”.

4 thoughts on “Estimating: Stop Trying Harder

  1. Pingback: #NoEstimates, what is asked from us? | Melle Koning Blog

  2. Hey Mike

    Estimating is one of those things in development that does not mean being more careful mean better results. Take coding, being more careful means better results. More careful estimates means spending more time, getting the same crummy results. I’ll add to what you say: If you need to estimate, find a fast way to do it and don’t expect to be right.

    James

  3. Pingback: Software Development Process - SEK's WikiDot

Leave a Reply

Your email address will not be published. Required fields are marked *