Book review – Debug It!: Find, Repair, and Prevent Bugs in Your Code

I bought Release it! some time ago, and it was a really good book. Now Pragmatic Programmer released a new book in their ‘do it!’ series – Debug it!, so when I got a change to snap a copy, I did, and I’m here to let you know that it is a remarkable book.

First of all, I think the title might be a little misleading for some people. It is about debugging in a broader sense than most people define it. If for you debugging equates dealing with debugger, you won’t find much of that in this book. The book talks about debugging as in getting the bugs out of your software (and doing your best to make sure they won’t come back).

The book is divided into three parts:

The first part, which accounts for almost half of the book, talks in great detail about four stages of dealing with bugs in your code – reproduction, diagnostics, actual fix and reflecting over reasons why the bug was there in the first place. There is not much earth shattering here, and when reading this part you’ll (hopefully) think to yourself – “yeah, I knew this” and “sure, it makes perfect sense”. The fact that this all common sense, and rules of thumb are gathered in one place though, and backed up by concrete discussion and good anecdotes helps you organize your workflow when dealing with misbehaving code. The fact that what you felt under your skin is said out loud makes you stop and realize there’s deeper meaning to all this.

Second part is relatively small, but concentrates on very important topic – working with people. That includes both, working with QA department and users as well as working with bug tracking systems. It discusses what makes a good bug report, what it should contain, what it should not contain etc. This part was a revelation, and if I could I would make it mandatory to read for all my clients, and people submitting bugs to OSS projects I contribute to. Then it moves to pragmatic approach towards working with bugs (hey, it’s a Pragmatic Bookshelf book after all). It talks about perfectionist attitude of bug-free software, and working with software that is riddled with bugs, which was interesting to read in the context of Tim’s post.

The final part, is a loosely connected group of topics, though it is as valuable as the previous ones. It talks about special cases, like service releases, about building the ideal debugging environment, which I found particularly interesting as this is topic close to my heart, although I would disagree with the author, who discourages extensive use of branching is source control. We also get a chapter on how to make software easy to debug. The book ends with list of anti-patterns along with discussion about how to remedy them.

I know that this book influenced the way I work now, and there aren’t many books I could say something like this about. It discusses extremely important part of software engineer’s profession, and does it very well. If you call yourself a pragmatic programmer I think you should read this book.