Debugging – the 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems by David Agans was published in 2002, based on several decades of practical experience in debugging embedded systems. Compared to the other debugging book I read this Summer, Debugging is much more a book for the active professional currently working on embedded products. It is more of a guidebook for the practitioner than a textbook for students that need to learn the basics.
The book lays out nine rules of debugging that the author has distilled from his own experience. Each rule is explained in quite some detail, using quotes from the Sherlock Holmes books as well as many war stories from the real world. The style is entertaining and irreverent, and I found myself laughing out loud as well as commiserating with the engineers in the stories.
The nine rules are (see the poster the author put online):
- Understand the system
- Make it fail
- Quit thinking and look
- Divide and conquer
- Change one thing at a time
- Keep an audit trail
- Check the plug
- Get a fresh view
- If you didn’t fix it, it ain’t fixed
Reading this book, I nodded in agreement to each of the rules. They all make perfect sense and describe most of the things that I myself have learned to do over the years. The rules describe a methodology of debugging that is timeless – these principles apply to any system, built in any way. They are most applicable to embedded systems containing hardware and software, but they apply even if you are trying to fix a car that won’t start (of which the author seems to have owned quite a few).
I think that reading the book and remembering the rules will actually be useful for myself going forward. Having a few rules of thumb like this makes it easier to be systematic about things than just relying on an unspoken informal idea about how to do things.
I actually found myself applying some of the rules during the writing of this blog post. For the past few months (ever since I upgraded to version 3.4 I think – should have kept an audit trail when I think about it), my WordPress installation has had the problem that the “Add Media” button in the editor failed to insert images into my posts (I did find a clunky workaround that kept me writing). However, I applied the rules (in particular, Change one thing at a time) to debug this, and managed to solve it. In the end, it turned out that the Open Web Analytics plugin conflicted with the editor in some way, and disabling it fixed the issue. Thanks to reading the book, I took the last point to heart and actually tested the fix by toggling the plugin on and off a few times, checking that I could indeed insert images when it was off and that I could not insert images when it was on. I am not sure I would have tested the fix quite as rigorously before reading this book.
A small nit with the book is that the explanations for the various rules overlap a bit, and I had a feeling that maybe they could be distilled into something even more general. But then again, making it too abstracted would reduce the practical value and easy translation into practical action that is the intention of the book. Better to explain a bit too much than too little and repeat some lessons an extra time.
The one thing that shows the book is a bit old is the fact that the modern Internet and its various forms of communications is missing from the text almost entirely. Sure, in 2002 we had email and the web, but if this book was updated today, I am sure there would be much more about social networking sites for programmers like StackOverflow as well as about working and communicating within geographically dispersed teams. Still, as I already stated, the rules are totally applicable today – just like they were in the 1970’s when the author started his career, and in 2002 when the book came out. They are, as far as I can tell, sufficiently general to be timeless.
I particularly appreciated the chapter on how to apply the rules when working the help desk and support function. I think this book should be mandatory reading for anyone doing support on complex software or hardware products.
Overall, highly recommended! And if the author would publish an updated edition, I would be all game for that too!
One thought on “Book Review: Debugging”