estimates estimation software Reflective Management

The Scene

I’ve worked in software engineering organizations for more than 20 years.  At some point every software developer is asked the question they’ve been dreading.

How long will it take you to build this feature?

The developer freezes.  Panic sets in.  Visions of a future where they didn’t meet their estimate come to mind.  If you were a good developer you would have got it done in time.  WHY did you get it wrong?  For a software developer, providing an estimate can be giving someone rope to hang you with.  Many developers have learned to be conservative about their estimates, or to add padding to give them some wiggle room.  It’s difficult for non-developers to understand is why estimating the time a feature will take is hard.

“You’ve been writing code for years, you’re only having to put some text up on a screen, it can’t be that hard, right?”

Developers know that there are lots of things that can go wrong.  The solution they have in their mind might not, in fact, solve the problem adequately.  There may be bugs in software they’re relying on.  The specification might change part way through.  It’s significantly more likely that the estimate will be wrong than right.

Try This At Home

Humans suck at estimating things.  To illustrate this point, here’s a test you can try at home.

  1. Take a deck of 52 cards.  Split the deck at a random place.
  2. Put one part of the split face up, and the other half face down.
  3. Now spread the cards out on the table, and mix them up.
  4. Estimate in seconds how long it will take you to sort them into one pile for each suit  (this is a short task, so seconds are an appropriate granularity).
  5. Estimate how long it will take you to sort each suit pile into numerical order, in seconds.
  6. Write those estimates down, get a stop watch and give it a shot.

I like this task for a few reasons :

  • This is a task with a very predictable end result, so no arguing about what ‘done’ looks like.
  • If you’ve played cards, you have done this before.  You should be able to provide an estimate.
  • There are variables here: how many cards are face up and face down?  How well mixed are the cards?

How Did You Do?

In theory, you have all the information you need to provide an estimate.  And the task is much more simple than building software.  When I run this experiment with people, they are surprised that their estimate is usually significantly wrong. If you get within ten seconds, plus or minus, you’re doing quite well.  If you do this task a second time right away, you’re likely to be closer the second time round.  You might get within 10 seconds this time; even if you do you probably didn’t hit the exact time.  So next time you’re discussing estimates, have some empathy — they aren’t easy and software development is significantly more complex than sorting cards.

Leave a Reply