Book Review: Debug It!

I started programming as a teenager. My first paid programming job involved writing a sort of mail-merge program in BASIC, on a TRS-80 Model II at my Dad’s office. Over the years, I figured out that by adding enough print statements here and there I could eventually figure out what was going on and make the bugs (or at least their symptoms) go away.

Another ten years or so passed, however, before I really learned how to debug software. That happened at my first job out of graduate school, when I went to work for a company that produced commercial software for computational fluid dynamics (CFD) analysis. The sort of scattershot debugging approach that I’d used up until then would no longer suffice. We had customers paying pretty hefty licensing fees to use our software, and when they reported a bug we needed to make sure that we could get a solid, reliable fix out to them so that their work wasn’t disrupted. It wasn’t enough to make the symptoms of the problem go away. We needed to understand what was broken, how it got that way, and only then implement a solution. Fortunately, one of my mentors at that company taught me this more rigorous approach to debugging software, one that I continue to use to this day.

Earlier this year, I had the opportunity to do a technical review of Paul Butcher’s new book, Debug It! and now that it’s been published I’m pleased to be able to review the final product. A number of classic programming books, such as Steve Maguire’s Writing Solid Code or Steve McConnell’s Code Complete, touch on debugging as one aspect of the software development process, but I’m not sure that I’ve ever seen or read an entire book devoted to the topic of debugging software. In that regard, Paul’s new book fills a pretty interesting niche.

Paul breaks the debugging process up into four stages: reproduce, diagnose, fix and reflect. These stages are covered in detail in the first five chapters of the book, and this is the most important section. In the chapter on reproducing bugs, he touches on topics such as how to control the environmental conditions under which bugs manifests themselves, and techniques for reproducing the inputs that trigger the bugs. He also addresses some of the difficulties involved in dealing with especially difficult-to-reproduce nondeterministic bugs. In the chapter on diagnosis, Paul moves on to the process of forming a hypothesis about what’s causing the bug and then performing experiments to refine that hypothesis until you settle in on a root cause. There are a lot of useful guidelines here, including my favorite: Only change one thing at a time! The chapter on fixing bugs is relatively short, which reflects the reality that once you understand what’s going on it’s usually not that difficult to fix the problem. Here the author stresses the importance of adding regression tests, and making sure that you’re fixing the root cause and not merely the symptoms. The last step is to reflect on the significance of this bug and what it might be telling you about the overall quality of your code (e.g. are similar bugs lurking elsewhere in the code?)

The second section of the book (“The Bigger Picture”) takes a higher-level look at the issues surrounding software bugs, namely, how do you create an environment such that you stay on top of bugs and not fall into an “infinite defects” situation. It addresses topics such as tracking bugs and working with users and the support staff to better understand the bugs they’re seeing in production. The third section of the book (“Debug-Fu”) is sort of a hodge-podge of more advanced topics, I suppose. Some of the information in these later chapters is arguably out of place in this book. For example, Chapter 9, “The Ideal Debugging Environment,” stresses the importance of having automated tests, a continuous build system, and so forth. There’s no question that this is good advice; I’m just not sure that it’s completely on-topic for this book. Having said that, they are good disciplines for any programmer to have, and if the stuff in the rest of this book is new to you there’s a good chance that Paul’s advice on testing and continuous builds is new to you too.

It is important to note that the focus of this book is the debugging mindset, and strategies and techniques that you’ll use when debugging software. It does not teach you how to use any particular debugging tools. If you merely want to learn how to use the GNU debugger (gdb), or the graphical debugger in your IDE of choice, this is not the book for you.

In conclusion, I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.