File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Testing and the fly likes Estimating bug fixes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Estimating bug fixes" Watch "Estimating bug fixes" New topic
Author

Estimating bug fixes

Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
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
author
Ranch Hand

Joined: Nov 26, 2009
Posts: 41
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.


paul.butcher->msgCount++

Author of Debug It!: Find, Repair, and Prevent Bugs in Your Code
Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
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
author
Ranch Hand

Joined: Nov 26, 2009
Posts: 41
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Estimating bug fixes