If, after twelve years or so of work, you find yourself bringing junior team members along and filling the role of mentor or lead, you are expected to impart your accumulated experience and wisdom onto the newcomers, so that the hard-won lessons need not become a re-nvention of the wheel. The most common problem in doing this is succinctly and effectively communicating the messages. This book does exactly that, for debugging problems.
It's worth noting that the author is very careful to distinguish between troubleshooting and debugging. Getting to the root cause of a problem is debugging; fixing the painful symptom(s) is troubleshooting. The analogy used in the book is this: instead of wiping off the oil spots so you don't slip and fall, secure the machine with four bolts instead of two. Keeping the floor clean is troubleshooting. Securing the machine so it doesn't vibrate, loosen the fittings, and leak oil in the first place, is debugging.
Debugging is hard. It requires discipline, attention to detail, and patience. The toughest leap of faith for anyone trying to adhere to the system might be in slowing down and proceeding in a meticulous, measured fashion; however, it is almost always exactly what's required to zero in on a problem's root cause, and accomplish the job.
Mr. Agans liberally fills the book with real-life war stories of how each rules is applied (or not applied); in some instances he can detail a good story illustrating every single rule. The rules cover exactly enough ground, and are reinforced well by examples. There's absolutely no filler in this book, despite any incomprehsible claim to the contrary. In fact, one might well wish for more examples in order to help make the necessary analogies to someone else when teaching from this book.
Here's a good example. It's my own war story showing how I used the rules, and how I didn't...
... I was trying to figure out why a particular application wouldn't export output to Excel. It was an out-of-the-box feature from the vendor, but the application is extremely complex to configure and I'd misconfigured something somewhere (it has to be me, no one else was brave enough to touch this application).
I had been wrestling with it, trying this configuration file and that one, all to no avail. I finally broke down and emailed the vendor, who put e in touch with a support specialist.
At this point, I had been changing too many things at once (rule #5 violated), not keeping a good audit trail because I was moving too fast (rule #6 violated), and clearly not looking (rule #3 busted). The only rule I'd tried was #8 "Get a Fresh View". The tide turned.
We started from square one, and rule #1 "Understand the System" came into play. We walked over all the possibilities, listing where exporting to Excel lays in the application. This also helped us to narrow down our search (rule #4, "Divide and Conquer"). Next, we started changing one thing at a time (rule #5) while keeping a good audit trail of what worked or didn't (rule #6). At one point, we'd revisited a section of code that sparked something in my memory. We'd downloaded a fix and forgot to fully test it. It was integral to exporting to Excel, so I backed out the fix, and export to Excel ow worked. It turns out the fix solved one problem but broke exporting to Excel. We put the fix back in, saw the problem (rule #2 "Make it Fail"), and backed out the fix. Now we'd proven that we'd found the real culprit. The vendor investigated and shipped us a new patch that worked *and* didn't break anything else.
If I had to teach all that to someone, I'd end up making a far less effective book than this one. Mr. Agans has done all the hard work here, and now I can give this book to junior team members, quiz them after reading it, and relate our own issues with respect to a common approach and means of describing the situation. Without a doubt, a classic book and one that every single professional problem-solver should own, in any field that has a diagnostic component to it.
-Fred
