16

(It is not a duplicate: Bug investigation is much more non-deterministic than a defined development task where things to be done are specified. Investigation is about narrowing a huge search space, which is different from building software. We cannot compare Memory Corruption bugs, C/C++ Undefined Behaviors, and Multi-Thread data races to scope-limited development tasks).

It's not the first time that my superiors are asking for an estimation when dealing about bug investigation. Just like it was a delimited development task.

I tend to prefer a scale of complexity. Something like: Easy, Not That Easy, Hazy, Difficult, and Really Difficult. And giving a time estimate only for easy investigations.

For simple investigations, I do agree that it is feasible. But I have no success in explaining them that a complex investigation is a cycling process:

  1. Reason about the facts, the code, the trouble
  2. Make hypothesis
  3. Find ways to measure the hypothesis by facts (traces, logs, debug...)
  4. If facts are clear and hypothesis is false, restart at 1.

It's a rather scientific/rationalist process indeed.

What other arguments could I tell, so as to explain the uncertainty in the very process of bug investigation?

Improve this question
5
  • 4
    @DocBrown I really don't agree withthe duppliate. I went to that Question before I made mine. The key point is that investigation is much much more uncertain that development, when things to be done are listed and specified.
    – Stephane Rolland
    Jun 2, 2015 at 13:28
  • 3
    IMHO the answers to that other question fit perfectly to your question. Especially the top answer.
    – Doc Brown
    Jun 2, 2015 at 13:31
  • 2
    @DocBrown: The top answer on that other question doesn't even mention bugs, much less take into account that frequently you want to fix a bug even though you don't have a clue what's causing it in the first place. It's not a bad answer for that question, but it doesn't address this question.
    – Michael Shaw
    Jun 3, 2015 at 16:24
  • @MichaelShaw: that other question is about estimations for software development and the fact it includes tasks with a high uncertainty. As you surely know, bug fixing is exactly such a task in software development - I do not believe I have to explain the latter. And as I already wrote, IMHO the answers to that other questions address the OPs problem very well.
    – Doc Brown
    Jun 7, 2015 at 19:18
  • 1
    @DocBrown: I'm not arguing that bug fixing has a low uncertainty, but a very high uncertainty. Like the OP, I think that at least for hard bugs, estimating the time they'll take is impossible. The other question's answers assume that estimation is hard, but possible. Those answers don't answer what his question asks. If you think we're wrong about bug estimation, an answer explaining why we're wrong would answer the OP's question.
    – Michael Shaw
    Jun 7, 2015 at 20:45

6 Answers 6

Reset to default
8

This isn't practically useful to you, but I wouldn't sink to the level of explaining to non-technical coworkers why certain technical tasks are harder than others. The point of hiring specialists for programming tasks who are better at technical things and worse at business or management things than their employers is that thy are better at them. To a large part, understanding why a defect arises equates to being able to fix it, and to a lesser degree to being able to avoid similar errors in the future.

Shortly and brutally, if your superiors could understand why some debugging tasks are so hard, they would be able to perform those tasks themselves - which they aren't, since they hired you. It's hard for anyone to accept that there are distinctions that they cannot appreciate, so there is little point explaining to a manager that you are having difficulties that you can't explain to him. The best thing you can do is to rise to his level of the view and tell him, "Look, I know this sounds lame, but I cannot tell you very well how long this will take no matter what the incentive". Once you've said this in the cases where it's true, and they have seen that it is actually true (because your effort did vary unpredictably), maybe they'll begin to believe you when you say that you dobn't know something. But I wouldn't hold my breath. Saying "I don't know" to something in a competetive environment is very hard to do, and many professionals avoid doing it at all costs; and so they tend to believe that it isn't true when someone else is saying it either. Strange, but (in my previous experience) all too true.

Improve this answer
3
  • 1
    "I don't know" is always a wise answer, I think, when asked for an estimate. Minimally, you should be seeking some amount of time to come up with your estimate. For a bug report, you should have time to review the bug report, reproduce it, and take a look at the code before you're asked to estimate it. It probably shouldn't be a huge project, but you likely can't just read a bug report and come up with a duration to fix.
    – Thomas Owens ♦
    Jun 2, 2015 at 13:21
  • 1
    Exactly. A team I recently worked on had some agile software, and we tried assigning points (estimated work effort) to defects, and it always came in vastly under or over. Oh, that looks like a 1 point defect. 20 hours later...
    – phyrfox
    Jun 2, 2015 at 15:53
  • @phyrfox: In that case, create some statistics. In a years time, you will have "526 bugs fixed in 1,278 hours". Even though each single bug is way off, if you have 53 bugs they will take you about 128 hours to fix.
    – gnasher729
    Jun 2, 2015 at 22:30
10

Depending on the severity of the issue and the urgency of fixing it, see if they'll agree to a "time-boxed" effort. Say, two days investigating/trying to re-create the problem. If you don't have it by then, you'll report on what you've eliminated as the problem and see if they want you to keep digging.

For minor issues, they'll likely agree to a short time-box as long as work continues on other issues or features. For major ones, especially those with major visibility, the time-box will let them get regular reports on your effort.

Improve this answer
2
  • I would add that a Technical Investigation (TI) Report is pretty much always useful, if the TI is not subsumed by an immediate bug fix (then the proposed solution would, in effect, be the TI). A good TI can lead to better planning, so the negotiated time box TI can help refine, and prioritize fixes (taking into account feature/cost/schedule/other impacts).
    – Kristian H
    Jun 2, 2015 at 19:31
  • @user11393 Basically you don't add any arguments for explaining the uncertainty of investigation. You classify bugs between major and minor, which is rather a "superior" point of view. You don't discuss the problem with complexity and non-determinism. Maybe you are unaware of it ?
    – Stephane Rolland
    Jun 3, 2015 at 8:12
6

Combine two approaches: the "fixed time estimate" and the "I don't know" approach without literally saying I don't know. Let's face it, if you knew exactly what is causing the bug you wouldn't have written it that way in the first place (yes, I know we don't always fix our own code, but isn't cleaning up someone else's mess even worse?).

Get into the habit of responding to bug time quote requests with, "I'll take a look at it and let you know how long it will take by ." People want to know that you care enough by demonstrating you're taking steps to solving the problem and that you're prioritizing their task appropriately. Making promises (and they are promises in their mind) you can't keep is going to decrease their level of trust in you.

Don't forget to reorganize your other commitments. In simple terms, I can't fix your new found bug and deliver a new feature at the same time. Which one do you want me to do first? Hopefully, they'll get the bug out of the way, but you never know.

They don't want a technical explanation. When a non-technical users asks, "Why is this going to take so long?" they don't necessarily want a technical answer and they really don't want details. By taking time to investigate the error and then giving a time estimate afterwards, you can also summarize the solution. There may be multiple areas of the app that need to be altered (The technical debt has now come due.), patching other technology, etc.

Improve this answer
1
  • I'm debugging and analyzing others code. It's daily work when in maintenance and/or support.
    – Stephane Rolland
    Jun 2, 2015 at 13:47
2

I suggest giving a range as an estimate.

For example, for easy issues it might be "between 15 minutes and three hours", for hard issues it might be "between two hours and a week".

This should get your point across. If they ask why your best and wost case estimate differ so wildly, you can start explaining the things you mentioned in your question (cyclic process, etc) and even give examples for the best and worst case.

Improve this answer
1
  • +1 All estimates should be a range, as a standard practice.
    – Eric King
    Jun 2, 2015 at 20:10
1

Looking for a solution to a problem can be a lot like looking for anything else that's missing. Take car keys for example. If mine aren't on the shelf where they belong, I check the other side of the shelf & a couple of coat pockets and usually find them in minutes.

When my wife lost her keys a while back, we had to wait for a snow drift to melt first. That took a couple of months.

I think you nailed it with "easy", "hazy", and "hard". A bug is easy to find when you can quickly narrow your search space down to something reasonable. It's hard when you can't.

All your superiors really need to know is that this is a priority, you're working methodically / you have a search plan, and you're not out of ideas yet.

Improve this answer
0

Time estimation for completion of tasks in software development is a dark art indeed. I think your arguments are good, but you forgot one critical one:

However much time you think it's going to take, multiply that by two.

I've found this to work quite well. Things will always take longer than you think it will, especially in software development.

Improve this answer
2
  • 3
    Arbitrarily multiplying your time is not wise. At a best case, overestimating will lead to work expanding to fill all available time and will require stronger time management to get done quickly and efficiently. At a worst case, over estimation can lead to understating delivery to a customer. You should always strive to make your estimates accurate and not artificially inflate or deflate them.
    – Thomas Owens ♦
    Jun 2, 2015 at 13:18
  • @ThomasOwens: Whilst I agree with your comment in principle, in practice I find that the multiplication approach works remarkably well for me. While I appreciate that this points to a deficit in my estimation technique, at least I'm systematically bad, and I have found an effective technique for compensating for my internal bias.
    – Kramii
    Jun 3, 2015 at 8:41

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