I have just purchased a copy of “Debugging” by David J. Agans.
You may be asking why, after thirty years experience, do I need this book? I probably don’t, but I know some people who could use it. Since I’ve been debugging for a few decades it mostly re-affirms what I already know and do. I wish I’d found the book when it was first published in 2002, it probably would have been dog eared and well worn within months of purchasing.
The book has a subtitle, “The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems”. That is exactly what this book is, nine guiding principles. Two of my favourites are
- “Quit thinking and look.”
- We often theorise with a prejudice, based on prior experience. Though gut reactions are good, they can get in the way.
- “If you didn’t fix it, it ain’t fixed.”
- How many times did a timing issue drift away with an extra debug print? I keep seeing hard delays in start up code, they are very much masking not fixing.
Each of the rules is later expanded upon and examples provided. If you are looking for how many debug log prints per line of code you need, where to place your ‘scope probe, or how to trigger your logic analyser, then you will be disappointed. This book is more like a lunchtime conversation with the old guy in the office, where he tells his “war stories” and passes on sagely advice. The 9 Rules are all there on one page towards the beginning, with an invitation to post them on the wall above your desk. The rest of the book is anecdotal, with many short tales of debugging victories or scars from the issues that took a week to find.
The notion of an engineer having a wall to pin anything on shows how this book is a bit out of time, gone are high sided cubes and even bookshelves in a lot of the companies I’ve recently worked with. It is just one of a few anachronisms in this book from 2002. Another sign of outdatedness is thinking that the younger generation knows nothing of turntables and vinyl — that is a trend that surprisingly reversed. Though the book is showing its age in some respects, the key points are still salient. There is a recommendation to read the entire data sheet. I used to do that, but the Technical Reference Manual (TRM) for some modern System on a Chip (SoC) and System on Module (SoM) devices can easily be a thousand pages long, and so you have to pick the blocks you read about.
The writing style is approachable and conversational, but that maybe only because I’ve know the author’s peers. They were my mentors when I started off in the 1990s. I’m not sure if the generation gap would be an issue. Don’t let the tone trick you into dismissing the information as no longer relevant.
There are illustrations peppered throughout. They remind me of my whiteboard, formal diagram types replaced by ad hoc block diagrams, timing diagrams and sketches of physical devices. The illustrations get the message across, and reinforce the notion that a picture paints a thousand words.
Though the book was published in 2002, my copy was printed on the 23 October, 2023. At first I thought it was a print on demand publication, but since I ordered it on the 26th, it can’t be; maybe it’s printed in small batches, or maybe I just chanced on a re-issue. Batch printing is probably cheaper, but warehousing costly, so there must be sufficient demand to make this model still economically viable.
For under $20 it’s a worthwhile add to the collection, good insights in an approachable format.
As an Amazon Associate I earn from qualifying purchases.