Highly Recommended Book: Debug It!
Posted by Davy Brion on 26th January 2010
I’m not the best debugger out there, but i usually manage to get to the bottom of things and sometimes i even enjoy chasing down a weird bug. And while i actively try to avoid bugs as much as possible, i’m also always looking to learn more techniques or practices to efficiently find and fix bugs when they do occur. So when i first heard about Paul Butcher’s Debug It, i immediately preordered it. And now that i’ve read it, i’m very glad i did.
The book is divided in 3 parts. The chapters of the first part explain in depth what kind of debugging strategy you’ll need. Discussed topics include:
- figuring out what you’re really looking for
- tips and tricks to come up with a reliable reproduction of the bug and the value of having that reproduction
- diagnosing the actual problem
- coming up with a true fix
- reflecting on why the bug ever got into the software
- making sure that the bug can’t come back and that we learn from the mistake
For some of you, most of this stuff will just be common sense. For a lot of developers though, this part alone should be considered required reading. It’s a complete process of how to deal with bugs efficiently in less than 80 pages! Think about that for a second: 80 pages that will improve your efficiency at your job and will reduce the amount of time you spend doing something you probably don’t like doing. How could you resist?
The second part is pretty short (only 2 chapters) but pretty interesting as well. It mostly deals with organizational patterns and practices that a development shop should take into account. It covers things such as:
-
the importance of bug tracking
-
what makes a good bug report
-
effective communication with users and support staff
-
giving priority to bugs as soon as they’re discovered
-
the importance of pragmatic zero-tolerance for bugs
-
ways to get out of a Quality Hole
Not all developers will like the second part, but it definitely contains some valuable information for technical managers, or for developers who need to convince their technical managers
The third part of the book deals with a lot of various strategies for a variety of specific situations. While not everyone will get something out of every topic discussed in this part, odds are that quite a few of them will indeed be interesting for you. You’ll find specific advice for quite a few special cases (performance, concurrency, backwards compatibility, third-party bugs, etc…). You’ll also find the obligatory chapter on creating an ideal debugging environment with automated tests, a build system and continuous integration. If you’re reading this blog, you’re hopefully already convinced of the values of such things so you might want to skip this chapter. The final 2 chapters are again very interesting… They’ll show you how you can write software that will debug itself. While not everyone will actually go out and do this, some ideas of that chapter should definitely be kept in mind by most of us. The final chapter deals with some common (mostly organizational) anti-patterns for dealing with bugs.
All in all, there is just a lot of tremendously valuable information in this book. And it’s only about 190 pages so it definitely won’t take you a long time to read it. I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur. And i’m not just talking about bad developers. I’ve seen plenty of good or even great developers having trouble with debugging efficiently. This book would definitely get them on the right track, with just a little bit effort.
Posted in Books | 3 Comments »