Book Review: Debug It!

The Pragmatic Bookshelf has released a new book into beta called Debug It!: Find, Repair and Prevent Bugs in Your Code, by Paul Butcher. Paul is a friend of a friend, I don't know him personally.

I like the premise behind this book. When I showed it to a friend on the train yesterday while reviewing it, he joked that we should just code it right in the first place! We all know that even on the best teams, the reality is that bugs happen. But, as Paul points out in his introduction, there aren't many books that cover debugging. Given that debugging can be a frustrating exercise, having a resource like this is a huge benefit to the professional software developer.

Paul asserts that debugging is an 'intellectual process', it's more about the approaches you take to identify and then resolve issues than the tools that you use. Despite covering a number of popular tools and techniques that make finding and dealing with bugs easier, the message is that you have to get the mindset right. He defines the core debugging process as:

• Reproduce
• Diagnose
• Fix
• Reflect
  

From these basics, Paul covers a set of approaches to help with each of these steps in the process. A lot of the approaches will be second nature to experienced developers, although it's good to be reminded now and again of some techniques that you can fall back on if a bug is proving to be particularly tricky to root out. The book is split into three sections:

• The Heart Of The Problem - all about the basics of debugging and the mental approaches required
• The Bigger Picture - tracking and managing bugs
• Debug Fu - some of the more interesting and advanced issues you have to be aware of when debugging and resolving bugs
  

One of the best features about this book is the number of real world debugging anecdotes that are told throughout the book. Apart from being amusing stories, the bizarre nature of some of these bugs should make anyone think twice before selecting the 'could not reproduce' option on their bug tracker.

In the Pragmatic Zero-Tolerance section Paul presents a great diagram that illustrates the effect of leaving bug fixing to the end of a project. He then provides some good rational for fixing bugs early. There are a number of team approaches described for 'Digging Yourself out of a Quality Hole', but no suggestions on how to manage early fixing of defects before you get into the hole. For the record, two approaches I have worked with are:

• In an XP environment, have a bug pair, that clears all the outstanding bugs in the iteration before starting on any user stories. Rotate the bug pair every iteration.
• In a Scrum environment, whenever a story is finished, the pair pick up a must fix defect before moving on to their next story.
  

There is a nice discussion of concurrency bugs and some techniques for identifying and fixing them. He agrees with other writers on the subject that simplicity is generally your best bet. Reduce the parts that are concurrent as far as you can.

A personal favourite of mine, and I was starting to worry that it wasn't going to come up, is the section entitled, Don't Be Too Quick To Point The Finger. This is aimed at developers that assume they couldn't possibly have made a mistake, it must be that 3rd party library that is broken, not their perfect code! I couldn't agree more with his sentiment that you should trust 3rd party libraries until you have proved, beyond a shadow of a doubt that it is not your code that is buggy. The library has probably been tested a lot more thoroughly than yours.

There is a real gem of a chapter in this book, which is all about assertions. When to use them, what to use them for, how not to use them. If you're after a short guide to the why and how of assertions, this is the chapter for you. Now here's the really good news -- this is available as a free extract.

There are some interesting organisational anti-patterns given in the last chapter, of which I have certainly seen a few so it is nice to see them documented from a debugging perspective. There was no specific mention of code anti-patterns, there's a section called Assertion Abuse, which strike me as anti-patterns for assertions. But a discreet set of code anti-patterns that are likely to lead to bugs would be useful. Some mention of code complexity on the effect of defects would have provided an interesting chapter.

Overall, I think this is a really useful book. It does a great job of setting the scene for debugging and getting you into the right mind set, while also talking about the complications that can arise once the bug is found and squashed. It's almost worth looking at for the anecdotes alone, to understand the lengths that you sometimes have to go to when trying to understand some truly bizarre defects.