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?

  • I would say before putting a number you first analyse the problem. If you failed to analyse you can t put a number, if you suceed you can put anumber.
    – Walfrat
    Commented Sep 15, 2016 at 9:42
  • 2
    possible duplicate of Time estimating of a complex bug investigation (not a straight-forward one)
    – gnat
    Commented Sep 15, 2016 at 9:43
  • I wouldn't go with your classificaton: The main issue with real-life bug fixing is reproducability, in my experience.
    – tofro
    Commented Sep 15, 2016 at 12:44
  • Basically, you nailed it: you can't ...and personally, I find it silly to attempt to. Management versed into programming usually knows that and cares mostly about prioritizing them. I pity those spending the day gazing at bugfix time estimate spreadsheets.
    – dagnelies
    Commented Sep 15, 2016 at 15:14
  • An estimate is how long you "think" it will take and not how long it ends up taking. If you discover new information that leads to an increase in your previous estimate, I suggest giving that bad news ASAP.
    – JeffO
    Commented Sep 15, 2016 at 16:25

2 Answers 2


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.

  • 2
    "...An estimate gives some information to your manager, and therefore it delivers some value. This is better than no value..." Unless of course, your estimate is way off, in which case you provided negative value, which is not better than no value.
    – Eternal21
    Commented Sep 20, 2016 at 18:39

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."

  • To the estimation, add the time it tooks to you to find out what was going on. Then add the time to fix it. Often the first takes longer than the second. But whoever is asking you, only wants to know the second part (only the estimation of the solution). So the answer is: How many time do I have to investigate it?.
    – Laiv
    Commented Sep 16, 2016 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.