The SquizLog

Should Just Take a Day...

"It should just take a day or two." How often have you said or thought that about how much effort you think will be required to complete a software development task? Only to discover later that there is more involved and it takes longer.

Estimating software development activities is a skill that deserves more attention. So I was pleased to see Ben Hogan and Mike Williams share their thoughts on the subject. Ben writes about the importance of using estimates constructively whilst Mike gives his opinion on the benefit of the XP style of estimating in units not clearly related to days.

Both comments touch upon the tendency to be optimistic and over-confident when estimating. And what Ben has to say appears to concur with what I've written previously about schedule pressure.

So why do I think estimating is so important? It's pretty obviously a key consideration for successful projects. Especially when you're involved in a fixed price project.

I don't think it is surprising that Robert Glass devotes a whole section to Estimation in his Facts and Fallacies of Software Engineering book. And it's hard to argue with what he says. Here are three of his "facts" on the subject:

Fact 8: One of the two most common causes of runaway projects is poor estimation.

Fact 9: Most software estimates are performed at the beginning of the life cycle. This makes sense until we realise that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.

Fact 10: Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.

I don't know about you, but these statements ring true with my experience.

There are no easy answers. The XP Planning Game is one attempt to deal with estimating problems but it isn't suited to fixed price projects. I think what is needed initially is an honest acceptance that building software is a complex business and inherently difficult to estimate.

And then a preparedness to do something constructive about it.

Posted to Software Development by Keith Pitty