Debugging: a very short review

Computer books come in all sorts of flavors. There are textbooks, users manuals, reference works, etc.

This short book by David Agans doesn't fit easily into any of the common categories: Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.

Debugging is one of those funky parts of the programming profession that doesn't get talked about very much. I'm not sure why that is, because it's quite clear to me, after three decades of programming, that debugging skills are one of the crucial characteristics that distinguish successful programmers from failed ones:

Successful programmers are able to debug programs, whether or not they wrote them initially.

I've seen a lot of people who wanted to become programmers, and failed, and in many of those cases the part they struggled with was debugging. They could write programs that were quite clear, well-designed, neatly-expressed.

But no program ever works correctly the first time; as the great Donald Knuth said: "Beware of bugs in the above code; I have only proved it correct, not tried it."

So, to be a successful programmer, you have to learn how to be successful at debugging.

Many programmers think that debugging is some sort of magical ability; either you have it, or you don't. I don't think that is true; I think you can learn debugging skills, and, much more importantly, I think you can improve your debugging skills.

Agans's short, fun, highly-readable book is a great way for you to learn or improve your debugging skills. Here's what Agans says about the goal of his book:

In this book I'll introduce the nine golden rules of debugging, then devote a chapter to each. I'll start each chapter with a war story where the rule proved crucial to success; then I'll describe the rule and show how it applies to the story. I'll discuss various ways of thinking about and using the rule that are easy to remember in the face of complex technological problems (or even simple ones).

The rules themselves are online, at Agans's web site, and they are nice and short and to-the-point:

1. Understand the system
2. Make it fail
3. Quit thinking and look
4. Divide and conquer
5. Change one thing at a time
6. Keep an audit trail
7. Check the plug
8. Get a fresh view
9. If you didn't fix it, it ain't fixed

You can get a sense of Agans's light and slightly tongue-in-cheek style as you read the rules, but in fact I like all his rules and think they're great.

If I could add one rule of my own, it would be:

Don't be afraid to try something.

I see so many people get stuck in debugging where they know there's a bug, and they can reproduce the bug, but they don't know what to do next. When I see this happen, I say to them: "what have you tried?"

Often, just asking them what they've tried gets them going again, but other times people are paralyzed by a fear that changing something is going to make matters worse.

Well, it might. But, you can't let that stop you from at least trying something. It may not be the right thing, but try it, and you'll learn from your experiment, and that will help break the paralysis.

Anyway, regarding Agans's book, I was pleasantly surprised: even after 30 years of experience, I found it a rewarding read, and I recommend it to anyone who's considering spending a significant portion of their life as a computer programmer.