4 ms·

I think you're reading it a bit too extremely. His point is that you always try to reproduce the bug before you assume you understand it. His comments don't s

by nertzy 18y ago

I think you're reading it a bit too extremely. His point is that you always try to reproduce the bug before you assume you understand it. His comments don't say anything about what to do if you're unable to reproduce. He's just suggesting in which order he thinks you should take certain actions. It's altogether too easy to jump straight to a patch, submit it, and miss the forest for the trees because you never actually went through the use flow and realized you were patching a symptom, not the underlying problem.

DenisM 18y ago
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 18y ago
  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 18y ago
    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.

by nertzy 18y ago

DenisM 18y ago

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 18y ago
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 18y ago
  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.