Q&A: An interview with author David Agans on debugging

• By Dan Romanchik
• November 18, 2002

[PROGRAMMERS REPORT, November 19, 2002] -- Slogging through complex debugging sessions is few people's idea of fun. But it is part of the program and improves every project when done well. David Agans is the author of Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, just out from AMACOM Press. We recently had the chance to ask David a few questions about the book and how it can help application software developers.

Q: Which debugging rules are the most applicable to application software development?
A: They're all critical. If you ignore one, it will bite you.

Having said that, there are some scenarios where some of the rules are less critical than others. If, for example, you're developing a very large application, the configuration tools and bug-tracking systems you use can help you with Rule #6, ''Keep an audit trail,'' and Rule #9, ''If you didn't fix it, it ain't fixed.'' It's not that you can ignore the rules, but that the systems prevent you from ignoring them.

Also, some developers naturally follow some of the rules. Application developers with good debugging tools tend to understand and use rule #4, ''Divide and Conquer.''

Q: What are the most common mistakes application software developers make when debugging programs?
A: The most common mistake is not understanding the system (Rule #1). The really serious bugs occur because no one has a big picture view of what the system is supposed to do. This is a design problem, of course, but that's a bug just the same, and trying to fix it at the coding level is a mistake.

I also think that application developers tend to rely too much on their debugging tools and they become a crutch. They go right to the tools to show them what's happening, without really understanding what's supposed to happen.

The next most-common mistake is thinking, not looking (Rule #3). All engineers make this mistake. It takes every bit of willpower to resist.

Q: How can developers improve their debugging skills?
A: They should start by keeping an audit of every debug session, taking note of not only what they do, but of what they think and decide. Take note of the time spent, too. Then, after a bug is found, do a postmortem and see what techniques helped, which ones misled. Note which sessions were quick, which ones dragged on and how the processes differed.

Use the rules to get bugs out of your debugging process.

Q: How can debugging be made easier?
A: Get some sleep. That will help [you] get a fresh view (Rule #8). Use the best debugging tools. Debug good designs. Read the book.

Q: Shouldn't application software developers work on their programming skills so that they can avoid debugging altogether?
A: Yes. And don't just work on programming skills. Work on product development skills, such as defining requirements and writing specs, that meet those requirements.

Don't just program -- design first. This is a big one -- there are a lot of engineers who 'design' as they code. Conduct design reviews both at the documentation and the coding level. And use great tools: good configuration control tools, powerful languages and thorough debuggers. Use a bug-tracking system that saves all the data.

By doing all this, the number of bugs will be greatly reduced. Not gone, but reduced. Which gives you more time to work on the ones that are left; and with the debugging rules, those will fall quickly. Maybe they'll even make that optimistic management schedule ... nah!

Links:
For more on Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems on the Amazon.com Web site, please go to http://www.amazon.com/exec/obidos/ASIN/0814471684/qid%3D1037373288/sr%3D11-1/ref%3Dsr%5F11%5F1/002-4328410-0747267

For other Programmer Report articles, please go to http://www.adtmag.com/article.asp?id=6265