Q&A: An interview with author David Agans on debugging
- By Dan Romanchik
[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
Q: Which debugging rules are the most applicable to application
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
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
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?
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?
Yes. And don't just work on programming skills. Work on product development
skills, such as defining requirements and writing specs, that meet those
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!
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
Dan Romanchik is an engineering manager turned writer and Web developer. His current passion is amateur radio. You can read his amateur radio blog at www.blurty.com/~kb6nu.