|
Re: Debuggers are a wasteful Timesink
|
Posted: Dec 1, 2003 8:54 PM
|
|
Well, I seem to have come into this thread a little late - that's the problem living at GMT+11!
This sort of conversation regularly comes up in programming discussion groups. Typically you get a bunch of people coming out of the wood, proudly declaring "I don't debug because I write brilliant code".
Well, just a few points on why in the real world, you need debuggers, and you need good ones!
* The term "Debugger" is a bit of a misnomer, because it is also an interactive learning tool for exploring the way a program works. Hence, more often than not I've fired up a program in a debugger, not to debug, but to understand how it works. This is particularly important when you inherit somebody else's codebase!
* "You can understand code just by reading it". Bullshit. Quite simply, utter bullshit. Why? Code describes the static structure of a process. A debugger allows you to look at the dynamic behavior of a process in action. No matter how smart you think you are, the number of states a non-trivial program can be in is vastly more than the mind can comprehend by "reading the code". How often does a innocuous looking method turn out to have a bug in it that only occurs as a result of an seemly unexpected sequence of inputs? Looking at the code, you don't even consider analysing how it would have behaved in that situation, because it "will never happen" thinks the developer. Then you fire up the debugger and surprise, surprise, it *does and did happen*. Why? Because the developer is not the user, and will frequently overlook common input situations. Debuggers provide a way to understand what is occurring in these unexpected, but commonly encountered situations.
Keep in mind, a "bug" is rarely as obvious as finding something like an incorrectly assigned reference - ie, something an "experienced" developer will pick up through a code review. Typically a program "bug" is not a code bug, but a design bug that did not take into account a certain scenario. The code looks fine, and may be 100% correct for the purpose it was designed for, but the "bug" is that there is a scenario that the design of the code never took into account.
* This above situation - programs behaving unexpectedly due to input unexpected by the developer, but in reality a common input in production/"the real world" - is why unit tests by themselves are not the answer. Unit tests are written by developers to test the *expected* behavior of their programs. Unit tests are a great QA & development tool - they improve the quality of the code, but they are not a 100% replacement for a debugger. Why? Programs do crash, and when they do, it's not necessarily because of bad design, or lack of unit testing, but because something unexpected has occurred - something so unexpected, there was no unit test for it.
* Unit tests are exactly that: a test on a self-contained unit. Programs are made up of a multitude of interacting units. The number of interactions in any non trivial system is so large that for it is a practical impossibility to write unit tests that consider every possible scenario.
* Programs crash, have bugs, run slow etc, not because a developer has deliberately coded them to behave like that, but because the actual way the program behaves does not match the conceptual model the developer has of how the program should behave. A debugger provides a way of verifying that your conceptual model matches the actual behavior of the program.
Whilst I agree with the original poster that debugging can be a drug and a lazy first stop analysis, I disagree that it's use should be discouraged. If a problem occurs, I tend to analyse the code, form a hypothesis of what is going wrong, then fire up the debugger to test that hypothesis, *before* engaging in any extensive refactoring. The idea of rewriting the "offending" code before running the original code through a debugger is just ludicrous - what if what you think was the "offending" code was actually not the real problem. Too bad, you have just spend 4 wasted hours recoding the wrong code, when 5 minutes with a debugger would have verified if you had correctly identifier the problem.
|
|