This question already has an answer here:
(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:
- Reason about the facts, the code, the trouble
- Make hypothesis
- Find ways to measure the hypothesis by facts (traces, logs, debug...)
- 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?