Debuggers: Threat or Menace?

Since I saw Robert C. Martin talk at CJUG, I added his weblog to my aggregator. A few days ago he made a post about how debuggers are a waste of time. I like Bob and I like his writing but I thought this was a pretty dumb position. I thought about blogging on it, but it kind of reads like something not atypical of the XP/Agile community – the “controversial attack on common practices mainly for the sake of stirring some shit up”. I kept his post around and every time I saw it, thought about writing something up but never did.

In the meantime, others have jumped in the fray, including Charles Miller and Brian Marick. I think there will be more. Some of what they said crystallized my thinking enough to go for it.

To begin, I’d just like to catalog for a moment how completely loaded Bob’s strawman argument against the debugger is. I’m going to list every value judgement in his short post, in the order it occurs.

  • debuggers have done more to damage software development than help it
  • It is not unusual for me to find a student with his or her nose buried in a debugger
  • painstakingly stepping from line to line
  • generally wasting time
  • I consider debuggers to be a drug — an addiction
  • the horrible habbit(sic) of depending on the debugger instead of on their brain

Bob suggests instead using print statements, code inspection and unit tests instead. I think you could rewrite his entire post and substitute “println” for “debugger” and have an equally compelling case – his argument is more with the strawman of “wasting time” than the debugger. I think he misses the point. My primary use of the debugger is not obviated by the unit tests but during the unit tests. When it takes more than 30 seconds or so to figure out why the unit test is failing, I set a breakpoint inside the failing method and set to to work. More often than not, I’ll see the problem quickly and fix it, and often this is far less time that it would have taken to fart around with a print statement. This is not in lieu of a code inspection, it is a code inspection but one that includes the runtime state of my program. I don’t see his anecdote about “students with their nose in a debugger” as a reason not to use one. Aren’t students, like, by definition learning how to do the task and learning the toolset? Their failure to use a tool at maximal efficiency does not to me say the tool is bad, but that they still have a way to go to use it best.

Using the debugger takes time, sure. Guess what – so does adding print statements, removing them, and making the decision when they should be commented out or removed. They are ugly artifacts in the code, and I hate to use them just to determine what a current problem is. This should all be differentiated from logging. I am a big fan of logging, and if the program state of that point is of ongoing interest, there should be a log message, preferably with a logging package and an appropriate level set. All this is different than a one-off println for a debug session. I just don’t like dealing with those. On the other hand, I’m not going to make a “print statements are a waste of time” assertion, because unlike many pundits I don’t claim to know the perfect universal toolset. Use what makes you productive and keeps your job fun. These might be different tools and practices than I like. I don’t consider that an error on your part.

Published by

dave

Dave Slusher is a blogger, podcaster, computer programmer, author, science fiction fan and father. Member of the Podcast Hall of Fame class of 2022.