Think and sleep.

I'm pretty sure that I first heard the term "brute force debugging" from my mom, who is also a programmer. I was writing about debugging this weekend, so I tried to find the origin of the term via Google. I didn't find the origin, but I did find some interesting lecture notes on debugging by Susan Hendrix of the Univ. of Colorado, Boulder. I really like Hendrix's guidelines for debugging. The first two are think and sleep on it. Great advice, wouldn't you agree? I really need to do more of both, whether I am involved in debugging or not.

Hendrix really doesn't like brute force debugging. She says that there are three brute force debugging techniques: 1) use of dumps, 2) scattering print statements randomly, and 3) over-reliance on debuggers. That doesn't sound quite right. My mom taught me that brute force debugging was the practice of placing well positioned print statements in code to locate where a bug is occuring. I like that definition better, but it is my mom's definition so what do you expect? If my mom was still programming today, I bet she'd be using Log4J, or something similar, instead of brute force debugging, no matter how you define it.


Like this post?  del.icio.us Bookmark it   |   submit to dig digg.com Digg it   |   slashdot Slashdot it   |   technorati See who links to it

Comments:

If you're using IDEA then you can use the option to print out any expression on a breakpoint, which is a GREAT replacement to log4j/system.out. These can be changed at runtime too, which makes 'em even more attractive to use. And they can be conditional. Just awesome.

Posted by Rickard on December 16, 2002 at 03:02 AM EST #

"Mom, who is also a programmer?" Now, that's simply cool :-D

Posted by Greg Klebus on December 16, 2002 at 04:09 AM EST #

Post a Comment:
  • HTML Syntax: Allowed

This work is licensed under a Creative Commons License.
Copyright 2002-2007, David M Johnson (dave.johnson at rollerweblogger.org)

This is a personal weblog, I do not speak for my employer.