Estimating bug fixes

[Michael Sullivan]

I forgot to ask this in my previous thread. One area which has been problematic is the estimation of bug fixes. Does your book cover how to estimate bug fixes, and how to react when you (undoubtedly) uncover new information that alters the original estimate?

The reason I think that this is important is that many times fixes are estimated with a 'best case scenario', before all the information on dependancies, implimention details, and possible bugs with the software platform/framework are available. I've often found that there is a much larger knowledge gap when estimating bugs versus estimation of a new feature.

Do you have any thoughts on this matter? Thanks!

[Paul Butcher]

Absolutely - it's covered in Chapter 7: Pragmatic Zero Tolerance, specifically in the section discussing the "Early Bug Fixing" approach.

In general, it’s impossible to estimate how long a particular bug will take to fix. Diagnosis is intrinsically uncertain - any estimate you come up with, until you’ve resolved that uncertainty, will be of very little value.

Once you’ve completed your diagnosis, you can probably come up with a good estimate for how long it will take to fix. But that’s not likely to be much help because, for the majority of bugs, diagnosis is the most time-consuming element.

All is not lost, however. Although you can’t estimate how long a particular bug will take to fix, you can make useful statistical statements about a collection of bugs. So, if in the run-up to a release you notice that on average you fixed twenty bugs last week, it’s probably reasonable to estimate that you’ll do approximately the same in the next week.

Early bug fixing exploits this effect - if we detect and fix bugs as soon as possible, we quickly discover what percentage of our time we need to spend on debugging to achieve bug-free software. Better, we do this without estimating - we simply measure how much time is spent bug fixing.

[Michael Sullivan]

I'm glad you brought these points out. Often we try to estimate the "fix", while the diagnosis takes the most time. The early/often bug detection/fixing sounds an awful lot like a velocity measurement where the focus is on tracking what has occurred vs predicting what we think will occur. I'm ramping up on a couple of new projects, and I'm going to try this out - it sounds like the best alternative.

Thanks!

[Paul Butcher]

Michael Sullivan wrote:The early/often bug detection/fixing sounds an awful lot like a velocity measurement where the focus is on tracking what has occurred vs predicting what we think will occur.

You've hit the nail bang on the head, Michael - that's exactly what it is.