On: The Greatest Bug of All

[DenisM]

It's still a dangerous path to go down, at leat in systems software. If your system collapses after 48 hours of stress load, what do you do then? How about 48 days? Still looking for repro? What if customer can't or won't hand over the data?

One will do well to learn debugging things from least amount of information - log files, crash dumps etc. Doing this consistently even for the easy bugs with repro will teach developers to put more information into log files and make data structures easier to discover within dumps. Then once hard problems come you will be ready.

[nertzy → DenisM]

I understand your sentiment but frankly I disagree.

Your first paragraph presents a straw man. Sure, in extreme cases, reproducing a bug is not mandatory. Again, the author does not claim that reproducing a bug is mandatory, but rather that it is a useful practice.

It is not a virtue to try to base your work on the least amount of information.

You say that "when the hard problems come you will be ready". But really when the hard problems come you will look at them assuming that the logged information is enough to solve them. No programmer can know ahead of time what information to log, so by purposefully blindfolding yourself from experiencing the bug directly, you might miss the bigger picture.

Indeed, I can't think of a reasonable logging mechanism that the author could have thought of ahead of time that would have helped with this particular bug. Emphasis on "reasonable".

[DenisM → nertzy]

Rather, when the hard problems come the logged information will be the only thing you will have. Eventually you wil solve all the easy problems with repro, and you will only have hard problems left. It's not a hipotethical, that is actually one step in evolution of systems software.