| Debugging is reverse-engineering, i.e trying to understand what's really happening inside a program. It necessarily implies some loss of control over the code you (or somebody else) wrote, i.e you're not sure anymore of what the program does - otherwise, you wouldn't be debugging it, right? If you get into this situation, then indeed, firing up a debugger might be the fastest route to recovery (there are exceptions: e.g sometimes printf-debugging might be more appropriate, because it flattens time, and allows you to visually navigate through history and determine when thing started to went wrong). But getting into this situation should be the exception rather than the norm. Because whatever your debugging tools are, debugging remains an unpredictable time sink (especially step-by-step debugging, cf. Peter Sommerlad "Interactive debugging is the greatest time waste" ( https://twitter.com/petersommerlad/status/107895802717532979... ) ). It's very hard to estimate how long finding and fixing a bug will take. Using proper modularity and testing, it's indeed possible to greatly reduce the likelihood of this situation, and when it occurs, to greatly reduce the search area of a bug (e.g the crash occurs in a test that only covers 5% of the code). I suspect, though, that most of us are dealing with legacy codebases and volatile/undocumented third-party frameworks.
Which means we're in this "loss-of-control" situation from the start, and most of the time, our work consist in striving to get some control/understanding back.
To make the matter worse, fully getting out of this situation might require an amount of work whose estimate would give any manager a heart attack. |