Customer Reviews

Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems

5 star:		(23)
4 star:		(2)
3 star:		(2)
2 star:		(0)
1 star:		(0)

 

 

This book is very useful for beginners and intermediate programmers. "Debugging" is full of practical advice on debugging in general. It is not tied to any particular programming language.

The book describes 9 main debugging "rules", and many smaller "sub-rules". The rules (such as "Make it fail" or "Quit thinking and look") and sub-rules (such as "Start from a known state" or "Build instrumentation in") are derived from common sense and years of experience. Many people know most of the rules, but perhaps do not systematically follow them. "Debugging" clarifies and makes a systematic review of the debugging practices, with examples taken from real life, simplified to remove the jargon.

The book is quite funny and makes enjoyable reading. I am looking forward to more: perhaps we can see more stories in the next edition, or in a companion volume, or on the debugging rules web site.

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

David Agans does a great job of explaining how to approach debugging as a science rather than an art. If you're a novice programmer, the information here will prove invaluable; discovering how to debug effectively on your own can take many years.

Experienced programmers may consider most of the rules to be obvious; however, those same programmers might be surprised to find how many of these obvious rules they neglect to follow. I've been debugging for more than 20 years, and still learnt some useful new tricks.

Peppered throughout the text are a large number of war stories from the author's own experience with embedded systems. As well as illustrating how to (and more commonly, how not to) approach a particular problem, these are all well written and often entertaining.

Some of my favourites: how wearing the wrong shirt to work caused a new video compression chip to crash; teenagers coming home from school subtly altering the behaviour of a video conferencing system; a vacuum cleaner that made the house lights flash on and off; a noisy read/write line that led a junior engineer to mistakenly redesign an entire co-processor memory circuit; and the self-test feature on an old Pong video game.

Although most examples are hardware related, the approach described can be applied to almost any problem; indeed, several of the examples used have nothing to do with computing.

This is not a large book, but it's well laid out, easy to follow, and doesn't talk down to the reader. It's also packed with enough meat to satisfy the hungriest of programmers. Highly recommended.

This book is absolutely indispensable for anyone working in any job where things occasionally work in an unexpected manner. It's concise, funny, well-written, and full of immensely useful tips on how to go about debugging problems.

One of the great things about this book is that it's generalistic in nature, not specific. Agans's decades of troubleshooting experience has given him great insight on how to go about debugging in all sorts of environments, so he lays out nine rules for approaching any problem:

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

[...]

Debugging isn't an art performed only by folks with some odd genetic disposition, it's a critical craft which can and must be learned. I was fortunate to have some good troubleshooters as mentors during my days working radar inflight in the Air Force, but I've fallen out of many of the good practices those folks beat^H^H^H^Hinstilled in me. Agans's book is helping me pull out of the thrash and churn mode of debugging.

This book's only 175 or so pages long and is well-worth adding to your library. Actually, substitute "a critical addition" for "well worth adding". I'm also going to make sure this book gets added to the professional development reading list I'm working on creating.

This book was not written specifically with software in mind, but I was very pleased to find out how it can improve the routine of any programmer. Since I read this book, I debug code in a much more "scientifical" and systematic way, instead of the old empirical, ad-hoc approach I had before (which seemed good enough for me at the time, since I didn't know any better)

Another interesting point is that his 9 rules apply very well if you use Unit Testing/Test-driven development, it feels almost as if the author wrote the book having TDD in mind!

A very nice and quick read, that will certainly make you a much more efficient developer (and car fixer, and plumber, and everything that involves debugging...)

The book pretty much spends the whole time explaining the 9 rules (which are pretty darn good), but unless you want to spend a lot of time reading examples or don't understand the fairly basic concept of the rules (also available at www.debuggingrules.com) it seemed like there was a lot of filler in the book. Many of the war stories were entertaining, but somewhat repetitive. Also, most of the war stories are based on hardware issues and circuit design. As a software developer without much of a background in Electrical Engineering I had a hard time following many of them. Would have given the book an extra star if he mixed in more war stories related to software.

I worked with Dave Agans for over 10 years and I can tell you first hand the man knows what he's talking about. From developing hand-held controllers in the late eighties to single-board OS/2-based videoconferencing products to software collaboration tools, we have debugged problems of every ilk. Whether the problem was an FPGA bug, a faulty component in a board, a race condition in a device driver or a dangling pointer in a DLL, Dave always approached the problem with his same set of debugging rules, and they never let him down. Read this book. It's engaging and fun to read. But more importantly it will make you a better debugger, whether you're debugging hardware, software or your lawnmower.

An excellent book of reference for novice to medium level user.
Mr. Agans' book presents real life experiences, or as he calls them war stories and humor filled comment/anecdotes.

I find myself chuckling and giggling along while reading this
book, some of what he said brought back my own memories while
working/debugging on my own software bug(s), or other people's
bug(s) that I have somehow 'inherited' because they left the
company, or are too busy on other projects to debug their own

code. I like the metaphors that he uses to explain ideas or
concepts that seems a bit too complicated to understand.

Mr. Agans made this very clear in the beginning of his book;
the book is not a cover-it-all book, it is a general concept
book on how to isolate, find, and debug something that has gone
wrong. The principles presented by Mr. Agans can be applied to
situations covering everyday life. He presented examples of well
pump and light bulb, etc...

More experienced software/hardware engineers or more experienced
problem solvers who read this book might find it covering bases
that they already know, but the humor makes it worth while.

Oh boy, how much easier an engineer's life would be if every tech book was written like this one. Let's face it, nobody likes debugging. The only thing worse is teaching someone else. Now it's easy, just give them this book. Better yet, give them this book, and make them debug your work. They might even enjoy it.

Quite liked it. I now have a game plan for approaching bugs in a nonrandom manner (including intermittent bugs):


Understand the System
- Read all related documentation
- Draw a system diagram and understand how things are connected
- Know the capabilities of your debugging tools


Make It Fail
- Start from a clean initial state
- Consider automating lengthy steps
- Make it fail in situ; don't waste time simulating the environment
- For intermittent bugs: list possible factors and try varying them one at a time; output a logfile and look for patterns


Quit Thinking and Look
- Watch it fail
- Use Remote Desktop / VNC
- Add logging and monitors
- Don't start thinking until you've limited the number of possible causes


Divide and Conquer
- Binary search
- Use test data with an easily identifiable pattern
- Start at the failure point and work backwards
- If you discover other bugs that may be related, fix them before continuing your search


Change One Thing at a Time
- Don't panic
- Back out changes that have no effect
- Compare the logfile with that of a good system
- Check earlier versions


Keep an Audit Trail
- Keep a detailed written log


Check the Plug
- D'oh!
- Have the components been properly initialized?


Get a Fresh View
- Try explaining the problem to someone (or something)
- Ask an expert: co-workers, the vendor, documentation, bug database, the web
- Report symptoms (including possibly unrelated observations), but not your theories


If You Didn't Fix It, It Ain't Fixed
- Fix the root cause
- Make the problem happen again by undoing your fix