Author: Paul Butcher
Publisher: Pragmatic Bookshelf
Pages: 232
ISBN: 978-1934356289
Aimed at: Every practicing programmer
Rating: 5
Pros: Excellent discussion of the strategy of debugging
Cons: Doesn't cover any specific technology
Reviewed by: Mike James

Some programmers are just better at finding bugs than others. Can this skill be taught?

Some books set out to tell you all about the most advanced and complex debugging tools and assume that if you are well equipped with such things then you will be a better debugger. This is certainly true but armed with the same tool some programmers will still be better at the job.

This particular book takes, in the main, a slightly different approach. It explains what the strategy behind debugging is all about. Put simply you have to work like a scientist. You set up a hypothesis and formulate an experiment to test it. It really is that simple. Of course there are lots of other issues such as finding and recognising a good experiment and formulating the right hypothesis and then there are the practical issues of how you go about implementing the experiment.

This isn't all the book has to say on the subject. It is full of interesting and useful anecdotes that are also used to make more general points. Some are obvious - make one change at a time, suspect your own code, first make the bug reproducible and so on. They still need to be said and we are all likely to make these mistakes as we relax into a comfortable relationship with code we think we know.

I particularly liked the "how did that ever work" section - so often after finding a bug you are left wondering how something so major could ever have allowed the program to work at all! In this case the principle is that you should go the extra mile and find out because the fact that you don't know how the broken code worked suggests that you might well have another bug lurking that allowed it to do so.

Author Paul Butcher goes on to explain the psychology behind  debugging and the nature of the "game" that is finding and fixing bugs. The book does touch on some tools and some principles, such as unit testing and refactoring, but this is not what the book is really about.

If you find that you are not quite as efficient at debugging as you would like to be then book this will explain to you what the task is. You will still have the problem of finding out how to implement the strategy, use the debugger of your choice and so on. You will also still have to make sure that you are on top of your subject and know how things work under the cover - but at least you won't regard finding a bug as a personal insult or a failure of your talent as a programmer. After all the point of testing and debugging is to find a bug - be happy when you do.

As long as you are not expecting a book to take you into any specific technology or teach you how to use a specific debugger then this is highly recommended. Buy, it read it and kill bugs.