Geek Smithology

November 14, 2006

Estimating is Bunk

Filed under: Craft of Dev by Nathan @ 10:38 pm

But I thought you beat the inevitability of death to death just a little bit – The Tragically Hip

I started a fairly recent talk on estimation poker with the following line:

Objective Software Estimation is Impossible

A slide emblazoned with a provocative statement, but not one without merit. As the shock wore off and the crowd grew restless I reached into the gaping maw of palpable disagreement for some input. Turns out I’m crazy – these Project Managers and Business Analysts had successfully shepherded several projects where the estimates turned out to be bang on. Even with big up front design. Seemingly debunked, I cast a line for what these projects had in common. A few of the answers:

“We had an excellent team with a lot of domain knowledge.”
“We had an excellent team with experience writing this type of application.”
“We had an excellent team and it was an expansion to an existing system.”

Touché. Or…not so fast. I’ll give you a moment to ponder the common thread woven through these finely honed ripostes. (No points for saying that good software depends on an excellent team – that’s obvious.)

Time’s up.

Did you get it? Each one of these statements is inherently and intensely subjective. I would be surprised if a team with a lot of domain knowledge building an extension to a system they originally implemented couldn’t estimate to within a single unit of work. But what happens when your crack Java Web Ecommerce SWAT team has to implement a .NET Accounting Application for Windows?

To predict the behavior of ordinary people in advance, you only have to assume that they will always try to escape a disagreeable situation with the smallest possible expenditure of intelligence. – Friedrich Nietzsche

The sad reality for too many of my developer brethren is that someone in a far flung Ivory Tower™[1] will create a giant specification, then giddily double click a Microsoft Project desktop shortcut to assign tasks and times. When the schedule slides (likely the next day, if not that day), some poor peon will get the near full-time task of updating the precious Gantt chart on a daily basis. By the power of Xenu, I wish this was a joke. In time the updates can’t outrun the inevitable domino cascade and Bad Things Happen. The autopsy will likely find the cause of death to be “insufficient analysis.”

I hear you, I hear you…”So Mr. Big Man, what’s your solution?” Since I’m not in the energizing, moisturizing, tantalizing, romanticizing, surprising, her-prizing, revitalizing tonic biz, the truth is I don’t have one. I don’t think that’s a failure, but a realization – I’m not the lone ranger, and the estimation problem may be a bugbear, but it’s not a werewolf. We need to base zero (or low) information initial estimates on the following, written in stone facts:

  • We cannot think of everything before we start.
  • You don’t know what you want until you see it.
  • User satisfaction comes from handling change, not mitigating risk.

Hell, there are no rules here– we’re trying to accomplish something. – Thomas A. Edison

This doesn’t suggest that our Big-Up-Front-Design needs to become Gargantuan-Up-Front-Design, but that we should take an iterative approach.

I refuse to believe that the resemblance between Gantt charts and waterfalls is purely coincidental.

[1] Why do we call these places “ivory” towers when they are employed in the practice of such dark arts?

Leave a Reply

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


Powered by WordPress