How to estimate bug fixes?

Question

How can you actually determine the size of fixing something which is broken in an unknown way? I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it! If those are the only two sizes available to us how can we possibly estimate them?

I got that from a blog by Bob Hartman but that's exactly my questions. Sometimes seemingly trivial bugs are hugely complicated and sometimes big issues get fixed by changing one tiny character somewhere. Then how can we ever know how long it will take without actually trying to fix it while estimating? And if I am going to fix it while estimating.. why am I estimating?

Answer 1

You cannot determine the size, but you can estimate it. An estimate gives some information to your manager, and therefore it delivers some value. This is better than no value, therefore you should take the trouble to make an estimation even if it won't be exact.

Why is this so? Because a business runs on repetition. Sure, telling your manager that making a fix has a 50% chance of taking less than a day is not hard information. But your manager has more than one report, an there is more than one day in a project. If your estimates are good, in the long run half of these issues will take less than a day, and this is a valuable thing to know when budgeting, planning, etc.

And how do you estimate? Well, you compare to the closest previous situations, and you guess. That's pretty much all there's to it. Obviously it takes some expertise to judge which situations are similar, and you'll sometimes get it wrong. That is not the point. The point is that no matter how inscrutable a problem seems to you, you, as the developer, have a better chance of making this judgement call than your higher-ups, therefore you are the logical person to make that call.

This is no different from an MBA hiring a programmer to program for him because he's better at programming: you get paid to perform a valuable service - in this case, reducing planning uncertainty for the project you're working on. It doesn't matter that you can't reduce it to zero - in business you have to think in marginal values, not absolute ones.

Answer 2

You estimate your patience with the problem.

Sometimes you have no idea what is causing the problem. No idea what it will take to fix it. How can you possibly predict how long it will take?

You predict how long before you'd give up and work on something else. Now you only need to understand the problem, not the solution.

If you don't yet understand the problem, the classic answer to this question is: "I'll get back to you."