Debugging is an interesting topic. All of us do it, but perhaps few of us really enjoy it. We may become masters of OOP; we may struggle to keep pace with the ever-changing Windows and Java APIs. But if we can't debug our own code, we're dead in the water as programmers. This leads to the question of whether debugging can be taught, not as a loose collection of techniques, but as a skill or formal discipline. I think the answer is mixed.
Let's start with first principles, where all good lessons begin. What are the principles of debugging? Frankly, I can't think of any, beyond "be methodical" and "tomorrow is another day." Certainly there are principles of programming, and applying them can result in fewer bugs, friendlier bugs, etc. But for this editorial I want to assume that the deed has already been done. The bugs are out there. Now how can we get better at finding them?
We can, to a certain extent, study debugging strategies. Examples of a few are divide-and-conquer, examine the most recent change, and make the bug reproducible. I lifted these from the excellent book, The Practice of Programming, by Brian Kernighan and Rob Pike (Addison-Wesley, 1999). This book includes a very helpful chapter on debugging, and is worthwhile reading in its own right. (Look for a review in a future issue of CUJ.) But studying strategies can take us only so far, for it seems we risk wallowing in the obvious. I question, for example, how anyone can have become a successful programmer without an instinct for divide-and-conquer.
We can also study debugging as a sort of science. Robert Ward, the founder of this magazine, is one person who made the connection between debugging and the scientific method. In his book Debugging C (now out of print, unfortunately), he says
The programmer creates nothing more than experiments during the debugging process. At this stage, the programmer resembles an FAA crash inspector. The programmer picks up pieces, studies them to discover why the program crash occurred, and evaluates possible fixes and safeguards.
If you are good at conducting experiments, you will probably be good at debugging. Maybe the best way to become proficient is to take a lab course in chemistry or physics!
There are pitfalls to the scientific method as well; the chief one is becoming too analytical. Some bugs are so weird they just defy analysis. A missing semicolon can create a raft of compiler diagnostics that don't mean thing. Try to analyze them and you may become downright antisocial.
So I guess I can identify one principle of debugging after all: there is no perfect way. Be methodical, but don't get a death grip on any single method. Knowing when to stick to it and when to try something else — this seems to be the key to effective debugging. I'm not sure it is taught anywhere but the school of hard knocks.
Speaking of trying something new: we welcome Stan Kelly-Bootle to the back of the bus, er, magazine, with his new bimonthly column, "Post-Mortem Debunker." Stan made occasional appearances in our Letters section and he got too close to our tractor beams. Check him out on page 104. A hearty welcome back to Bobby Schmidt, our Q&A guy, from his brief sabbatical in May. Bobby, we have a few questions saved up for you. Finally, we wish a restful month upon Dan Saks, who is sitting out this issue to contemplate the mysteries of const. He'll be back next month to share more of his discoveries.
Marc Briand
Editor-in-Chief