Throughout my career as a professional software developer, I’ve spent quite a lot of my learning time to sharpen my debugging skills. I’ve always considered this as one of the required abilities of a true software craftsman. I also strongly believe that the time spent hunting bugs should be minimized as much as possible. Other required disciplines like Test-Driven Development should prevent using your debugging skills as much as possible. But when the shit hits the fan, being able to fall back on solid debugging skills is essential for any software engineer.
Long time readers of my blog know that I’m a huge fan of John Robbins’ books on the same topic. So when Paul Butcher, the author of Debug It!, asked me to give his book a read, I wholeheartedly accepted. And I’m very glad I did.
Most people automatically think about their favorite debugger tool when they hear or speak about “debugging”. This is not what this book is about. This book is about the intellectual process of fixing bugs. Just as Red-Green-Refactor, debugging is a discipline with its own core process.
The book is divided into three parts, each of which shines a light on a specific aspect of debugging as a whole. The first part both provides an overview as an in-depth explanation for each of the steps in the debugging process.
For more experienced developers this might just be a recap of the process they already know and follow. For less
experienced developers, this first part provides a treasure of information that many of us have learned the hard
way throughout our career.
The second part talks about how debugging fits into the wider software development process. Topics like bug tracking, dealing with users/support staff, prioritizing bugs, software quality, etc. … are discussed in the two chapters that constitute this part of the book.
The third and final part is composed of a number of more ‘advanced’ topics. A number of strategies are discussed for dealing with special cases like patching, concurrency bugs, Heisenbugs, performance bugs, bugs in third-party software, etc. … . There’s also a chapter that describes the ideal debugging environment, basically evangelizing automated tests, source control and automatic builds which are pretty basic things for most of us but unfortunately not everyone. The chapter on self-debugging software was quite interesting as well as the final chapter on anti-patterns which is also highly recommended. I was personally intrigued by the author’s take on maintenance teams, which reinforced my opinion on the matter (this might be a future blog post).
This book also contains a vast number of anecdotes and short stories about real-world scenarios that help illustrate the different topics and enforce the points that the author tries to make.
Again, this book is highly recommended as it contains a whole lot of wisdom and experience from the field of software engineering. It’s only 190 pages, so you should be able to get through very quickly. So, you can’t lose on this one.
I know that I’ve been posting a lot of book reviews lately. I’ve been enjoying a quiet three week vacation at home so I’m making a futile attempt to catch up on my reading. I’ll probably have one or two more book reviews coming up.
