John D. Mitchell's Blog

Keys to Debugging

My buddy Terence Parr just published an article on developerWorks called Learn the Essentials of Debugging. In it, he brings up a number of essential debugging facets: Reproducibility, Reduction, Deduction, Experimentation, Experience, and Tenacity. Those six are certainly important but they aren't the whole story.

The first one that I'll add (based on the classic, nagging wife story... :-) is: Ask for help! Tom did what he could to figure out the problem and then he asked for help. Unfortunately, the boys forgot to ask me (an email expert that they know) and wasted a lot of their time -- the quoted-printable issue was the first thing that came to my mind. Doh!

However, like any problem solving process, the most crucial aspect of debugging is a more subtle issue... Admit that there is a problem. Now, obviously, Tom certainly realized there was a problem because he was actually testing his code and paying attention to the results. But, look around you. Have you noticed how many "issues" are missed, denied, and otherwise ignored? Look at the various bug databases (like the Java BugParade) where real, serious issues are ignored or outright denied for years. And, heck, at least someone bothered to recognize those problems and report them. Think about how many problems are completely missed because so many developers do only lackadaisical testing (let alone documentation or design work). Even more insidious are the higher-level dysfunctions such as the head-in-the-sand denials that I pointed out in Anatomy of Insanity?.

Humane development processes attempt to address this issue in various specific ways such as pair programming, code reviews, test-driven development, etc. The fundamental technique is increasing the cyclic rate of feedback at each level so that we will get used to listening to the feedback and then act in response to what we learned.

Comments

• Lots of generalized statements here. The usenet newsgroups and forums are full of people asking for help, many without replies. Maybe smart people don't want to ask for help first! If everyone emailed me the first time they hit upon a problem I would spend all day just reading email, not that I don't spend all day reading email as it is.

  
  The 'problem' with programming is it is still an art, not a science. A science would have tolerances, failure points, replaceable parts. Think of any other engineering discipline than software. Now the trend at least in the USA is to find the cheapest developer offshore that can maintain an acceptable level of quality.

  Some bugs in bugparade exist because we couldn't reproduce them, 5.0 brings in a lot of tools that hopefully will fix that.

  Posted by: calvinaustin on December 09, 2004 at 12:08 PM

• There is plenty of blame to go around when it comes to bugs, it is easy to blame the developers, cuz, hey, we coded them, but to paraphrase an authority whom I can't recall... "if it's in the code it's in the team", unclear/incorrect specs, business putting pressure on developers to add features over fixing bugs. I've even seen business not allow developers to just "fix a bug", because the testing department has to test the fix, and testing is backed up to next year testing all the new functionality. While XP flattens the change of cost curve, I sometimes wonder about the exponential, cost associated with bugs and leaving them in your system. Seems the best tactic is not to have any.

  Posted by: emeade on December 09, 2004 at 01:16 PM

• Calvin: Excellent. You've brought up the last item when it comes to humane problem solving processes: First, do your homework. How many of those plaintive help messages are resolvable with a simple read of a man page, an obvious search engine query, a search through the FAQs, or a simple experiment or two? In terms of the point of asking for help, this point of doing your homework is about asking for help -- just without imposing on other people unless you need to.

  Yes, of course software development is an economic issue. As so many people are learning in outsourcing to the cheapest bidder, it's usually true that you get what you pay for. I.e., penny wise, pound foolish. Alas, this insanity often "works" because of the asymmetrical risk/reward for the managers of such projects. That is, the manager gets to e.g., book the savings of firing a bunch of high-paid local workers immediately whereas they usually don't have to reap the consequences of the e.g., failed project (because they've already moved on to another job and/or they've been able to redirect blame elsewhere).
  

  Posted by: johnm on December 10, 2004 at 08:28 AM

• Erik, software is indeed an economic endeavor. Software development happens within larger contexts and is usually driven by the needs and constraints of those larger contexts -- this is an exact analogy with our conversation about pace, balance, and rhythm. There are always tradeoffs. Alas, the training of most developers and almost all managers (in addition to our own sillinesses) leads to very poor models and intuitions of those tradeoffs in all but the most simplistic systems.

  Second, as to "if it's in the code, it's in the team", that's exactly the point of my blog Anatomy of Insanity?. I suggest reading through the comments to that blog as you'll literally see that in action.
  

  Posted by: johnm on December 10, 2004 at 08:40 AM

• I know John, I already had, thats why I put it in ;)

  Posted by: emeade on December 13, 2004 at 01:07 PM

This work is licensed under a Creative Commons License.