What do you think?
Rate this book
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
When the pressure is on to resolve an elusive software or hardware glitch, what’s needed is a cool head courtesy of a set of rules guaranteed to work on any system, in any circumstance. Written in a frank but engaging style, this book provides simple, foolproof principles guaranteed to help find any bug quickly. Recognized tech expert and author David Agans changes the way you think about debugging, making those pesky problems suddenly much easier to find and fix. Agans identifies nine simple, practical rules that are applicable to any software application or hardware system, which can help detect any bug, no matter how tricky or obscure. Illustrating the rules with real-life bug-detection war stories, Debugging shows you how Whether the system or program you’re working on has been designed wrong, built wrong, or used wrong, Debugging helps you think correctly about bugs, so the problems virtually reveal themselves.
192 pages, Paperback
First published September 23, 2002
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 37 reviews
June 26, 2015
As I've said about other software engineering books (and my review for "Debug It!"), there's a fair number of useful ideas in this book, and enough dubious ideas to hold back any forceful recommendation.
First things first: the "9 indispensable rules" are neither a checklist nor a rubric. They're aphorisms and rules of thumb. And just like everyday aphorisms (like "a bird in the hand is worth two in the bush"), most of the principles in this book (like "check the plug"):
- are simple enough to seem useless when you first hear them,
- actually contain a really useful idea that's worth internalizing,
- can help you in a great number of situations, but
- are also absolutely wrong in many other situations.
As a result, the best way to view this book is a collection of things to think about when debugging, rather than a rigorous methodology or procedure. (I actually like that the book talks broadly about technical concerns rather than being dogmatic about a specific approach, but the set-up is problematic because it invites blind adherence when a thoughtful application is more appropriate.)
The writing and the rules themselves are a bit muddled, and that can really lead readers down a wrong path. The best example is the rule "quit thinking and look", which could be much more accurately (and not less succinctly) called "stop guessing and gather data". I get what the author wants to say, but telling people to "quit thinking" isn't what he means. That's actually the opposite of what inexperienced engineers need to learn about debugging. Worse, there's a strong tendency for people to take such pat one-liners out of context, and the author invites that by promoting the rules themselves rather than the ideas.
In summary: as with "Debug It!", there are useful ideas here, but they should be considered very thoughtfully.
First things first: the "9 indispensable rules" are neither a checklist nor a rubric. They're aphorisms and rules of thumb. And just like everyday aphorisms (like "a bird in the hand is worth two in the bush"), most of the principles in this book (like "check the plug"):
- are simple enough to seem useless when you first hear them,
- actually contain a really useful idea that's worth internalizing,
- can help you in a great number of situations, but
- are also absolutely wrong in many other situations.
As a result, the best way to view this book is a collection of things to think about when debugging, rather than a rigorous methodology or procedure. (I actually like that the book talks broadly about technical concerns rather than being dogmatic about a specific approach, but the set-up is problematic because it invites blind adherence when a thoughtful application is more appropriate.)
The writing and the rules themselves are a bit muddled, and that can really lead readers down a wrong path. The best example is the rule "quit thinking and look", which could be much more accurately (and not less succinctly) called "stop guessing and gather data". I get what the author wants to say, but telling people to "quit thinking" isn't what he means. That's actually the opposite of what inexperienced engineers need to learn about debugging. Worse, there's a strong tendency for people to take such pat one-liners out of context, and the author invites that by promoting the rules themselves rather than the ideas.
In summary: as with "Debug It!", there are useful ideas here, but they should be considered very thoughtfully.
July 15, 2017
"This book tells you how to find out what's wrong with stuff, quick. It's short and fun because it has to be -- if you're an engineer, you're too busy debugging to read anything more than the daily comics."
Примерно с этого начинается первая глава. Тут всё правда. Книга небольшая, книга весёлая и в ней всё по делу.
Книга именно про отладку. Причём не делается акцент, что это должна быть отладка софта. Автор, судя по историям, успел поработать и с софтом и с железом, поэтому на чём-то одном не зацикливается. Вот есть проблема, вот правила, которые нужны применять, чтобы её найти и починить (правило про Quit Thinking and Look вот прям очень хорошее).
В книге куча примеров (war stories). Многие из них не про программирование (машины, которые не заводятся; окна которые пропускают воду; видеочип, работа которого зависит от рубашки тестировщика, etc.). Из-за разнообразия, правда, не всегда понятны детали. Но читать всё равно интересно.
Не могу сказать, что после прочтения я стал ошибки находить в два раза быстрее. Но в каких-то сложных случаях советы (Quit Thinking and Look, Keep an Audit Trail) реально помогали.
Рекомендую. Сам прочитал два раза подряд.
March 21, 2018
A solid book on general (timeless) debugging principles. As I read this book I noticed I seemed to (almost magically) be debugging more effectively. Also, this book recommends that you learn your debugging tools well, so I learned and practiced using PyCharm's debugger well, which has made a huge difference when I'm debugging Python code.
March 12, 2022
All in all, solid advice that's at a good abstraction level, not getting so detailed as to be not generally applicable. My main knocks are that it really deserves an update for modern software development and the author's tone might be too much for some. (It was usually okay for me, but I did get annoyed a number of times.)
I'd recommend it to anyone who feels like they have something to learn about debugging. It's not long, and the style does make it a fairly easy read.
While the first rule still remains relevant (seriously, more devs should read documentation and code), it's certainly not as feasible to cover as much system understanding now than it used to be. If you're in the JS ecosystem, good luck with understanding the system!
I don't think anyone obeys all the rules all the time while debugging, myself included, but also probably everyone could do them more often. For me, that would primarily be keeping an audit trail!
I'd recommend it to anyone who feels like they have something to learn about debugging. It's not long, and the style does make it a fairly easy read.
While the first rule still remains relevant (seriously, more devs should read documentation and code), it's certainly not as feasible to cover as much system understanding now than it used to be. If you're in the JS ecosystem, good luck with understanding the system!
I don't think anyone obeys all the rules all the time while debugging, myself included, but also probably everyone could do them more often. For me, that would primarily be keeping an audit trail!
September 9, 2018
In my view this book was too long.
The rules are clear, make sense, but they were introduced by A LOT of war stories, most of them related to how you debug hardware problem. I had some issues following all the explanation there.
The rules are clear, make sense, but they were introduced by A LOT of war stories, most of them related to how you debug hardware problem. I had some issues following all the explanation there.
May 17, 2022
The most important point of this book is reminding: debugging is full of methodology!
The idea sounds natural after pointing out, but in practice, very often, we wading through the bug forests, navigating or lost in the software maze, we forgot this.
Before reading this book, I already sensed this so it's a good time to read it.
The book has a good coverage overall, understand the system, know the limit of the tools, stop
The big downside however, is the elusive writing of the hardware case study. As a software guy, they are really hard to follow, plus seems too much tied to a specific problem. The author spent lengthy space about them. Even worse, he diligently trying to callback the case in the principles. This can really be more concise.
I also don't like some arguments. e.g. "troubleshooting is different from debugging." "don't stimulate the bugs, but stimulate them." They are just word game and exists only for the sake of having comparison?
My approach to digest this book: focus on bold text and titles, be selective and conscious of them, try to see if you can find past experience correlatable for proof, counterexample, further thoughts, etc.
summarize it.
worth a read, for sure.
The idea sounds natural after pointing out, but in practice, very often, we wading through the bug forests, navigating or lost in the software maze, we forgot this.
Before reading this book, I already sensed this so it's a good time to read it.
The book has a good coverage overall, understand the system, know the limit of the tools, stop
The big downside however, is the elusive writing of the hardware case study. As a software guy, they are really hard to follow, plus seems too much tied to a specific problem. The author spent lengthy space about them. Even worse, he diligently trying to callback the case in the principles. This can really be more concise.
I also don't like some arguments. e.g. "troubleshooting is different from debugging." "don't stimulate the bugs, but stimulate them." They are just word game and exists only for the sake of having comparison?
My approach to digest this book: focus on bold text and titles, be selective and conscious of them, try to see if you can find past experience correlatable for proof, counterexample, further thoughts, etc.
summarize it.
worth a read, for sure.
February 16, 2021
This is a fantastic, practical book full of really solid wisdom for troubleshooting systems. It emphasizes many of the things that we often neglect by over analyzing the situation. The best rule, in my opinion, is "Quit thinking and look": an exhortation to closely examine the problem, in its entirety, before thinking about solutions. I have seen both myself and others pontificate and ruminate on the potential solution to a problem while the issue itself was staring us right in the face if we bothered to just examine it closely.
Granted, this book is written from the perspective of someone who has an electrical engineering background, meaning it may have some examples that are inaccessible to anyone not familiar with the trade. I think the hurdles to understanding are low, and the book is written in very clear language that will benefit anyone looking to improve their mindset with troubleshooting.
Granted, this book is written from the perspective of someone who has an electrical engineering background, meaning it may have some examples that are inaccessible to anyone not familiar with the trade. I think the hurdles to understanding are low, and the book is written in very clear language that will benefit anyone looking to improve their mindset with troubleshooting.
April 29, 2022
This was assigned as part of the reading in a CS course. It was written in 2002, and, honestly, feels like it was written in 1972. The content itself is fairly straightforward and focused on debugging hardware and oftentimes hardware related to TV and radio, not modern tech. The language used is cringey and outdated, it assumes every reader is an older male. I let the prof know it should probably be replaced with something a little more modern that emphasizes debugging on tech that is at least from the last 10 or so years.
September 28, 2020
I enjoyed the book, but a little less so toward the end. The initial rules are more important and interesting, their chapters were more engaging reads. The chapters for the last two to three rules were less interesting to me (and shorter content). The extra chapters after the rules (recap etc), felt redundant. The writing style and anecdotes are dated, but mostly this made the book more enjoyable for me, good job to Mr Agans.
July 11, 2020
Good book, entertaining to read, some very good field stories that most engineers, specially those in electronics, will surely enjoy. There are no big new ideas - the author admits it is mostly formalized common sense. Regardless, simply formalizing is valuable as it allows you to have a good grip on what NOT to do and why you do things in certain way.
January 31, 2022
This book is to debugging, what Clean Code is to programming. Which is to say: Though it contains outdated examples, and sometimes the advice is too idealistic and stringent, it is still a helpful list of fundamentals every engineer (and people dealing with engineering-like problems) should go through once.
May 25, 2018
I really enjoyed this book. I recently did a talk about debugging and there was a lot of overlap. Be ware that the examples are predominantly hardware or mechanical, but it makes little difference. This is a great resource.
August 13, 2020
A lot of this I knew instinctively, as will surely be true for any of us who have to debug as part of their jobs, but this book distilled this knowledge succinctly into 9 simple rules, with great "war stories" to help us see the application of these rules in "real world" scenarios.
July 9, 2023
It's remarkable that despite the rapid changes in tech, the concepts presented in this book remain relevant two decades after its publication. However, the 'war stories' in this book are quite dated which makes it challenging to read.
September 14, 2017
If you're a programmer: read this book!
January 6, 2019
A good systematic way to debug problems, worth practicing. The examples are outdated but nonetheless help the reader to understand the techniques.
February 29, 2020
One of my favorite engineering books because it explains in an easy way the steps to debug machines and systems.
March 3, 2020
Fairly basic, but some fun anecdotes.
Want to read
November 19, 2021[]
March 26, 2023
One of the most pragmatic books about debugging
April 30, 2023
The reference on the method of debugging
The book is good at explaining and illustrating the fundamental steps of any debugging situation. Helpful for experienced developers for taking a step back on their method, improve their debugging discipline and for training purposes. Also helpful for junior developers wanting to accelerate their learning curve.
The book is good at explaining and illustrating the fundamental steps of any debugging situation. Helpful for experienced developers for taking a step back on their method, improve their debugging discipline and for training purposes. Also helpful for junior developers wanting to accelerate their learning curve.
January 7, 2021
This entire review has been hidden because of spoilers.
August 24, 2018
This is a very important, short, accessible and fun book.
It's based on the 9 rules which form a basis for every debugging process:
1. Understand the system
2. Make it fail
3. Quit thinking and look
4. Divide and conquer
5. Change one thing at a time
6. Keep an audit trail
7. Check the plug
8. Get a fresh view
9. If you didn't fix it, it ain't fix.
The author goes through each rule step-by-step and present "war stories" to demonstrate the rules in action.
There's also a chapter providing an alternative "view from the help desk" which I've found very useful.
You won't find very many concrete tips on how to deal with / spot particular programming errors and/or tool recommendations in the book.
It is your fundamental guide to start from "first principles".
I don't think you should stop looking for more resources/books after finishing this book, but I do think it is an essential (first?) step in becoming debugging master.
It's based on the 9 rules which form a basis for every debugging process:
1. Understand the system
2. Make it fail
3. Quit thinking and look
4. Divide and conquer
5. Change one thing at a time
6. Keep an audit trail
7. Check the plug
8. Get a fresh view
9. If you didn't fix it, it ain't fix.
The author goes through each rule step-by-step and present "war stories" to demonstrate the rules in action.
There's also a chapter providing an alternative "view from the help desk" which I've found very useful.
You won't find very many concrete tips on how to deal with / spot particular programming errors and/or tool recommendations in the book.
It is your fundamental guide to start from "first principles".
I don't think you should stop looking for more resources/books after finishing this book, but I do think it is an essential (first?) step in becoming debugging master.
July 21, 2012
This is a great book on how to debug systems — not like how to use a debugger, but how to think. It's brilliantly laid out for someone new to the discipline, but even if you're experienced it's well worth a read for the clarity of the 9 elegant principles the author identifies, and for the many memorable "war stories" he describes from his own engineering career to illustrate them. (In my favorite war story, an intermittent video-processing bug was eventually traced to the plaid flannel shirt the author happened to be wearing on the days the bug occurred.) It's also very well-written and often funny. I borrowed it from a friend who says he recommends it to every technical person he works with. I second that recommendation.
June 12, 2013
This book is probably the most useful book I could recommend for anyone in the IT industry. The title probably does the book a disservice, because it's really a broadly useful troubleshooting guide, although the title wouldn't necessarily indicate that.
I've read the book before, and decided to revisit it, as I probably will every now and again. It does a great job of collecting and organizing the principles of skillfully tracking down issues. I wish that I could make this book required reading for everyone I deal with. Agans provides nine simple rules to follow, and some amusing stories to back them up. It's a quick and fun read.
As a manager, I've started to realize that some of these principles apply to people problems as well.
I've read the book before, and decided to revisit it, as I probably will every now and again. It does a great job of collecting and organizing the principles of skillfully tracking down issues. I wish that I could make this book required reading for everyone I deal with. Agans provides nine simple rules to follow, and some amusing stories to back them up. It's a quick and fun read.
As a manager, I've started to realize that some of these principles apply to people problems as well.
May 15, 2015
useful but more involve hardware,
i read it,when i have to accept a project "smartwave" ,whose maintainer have leave.
i constantly debug and find what and where i need.i used the way such as know the system,find bug from downstream,log the debug system and so on.so the book is useful,
but i metioned the soft developer,you can read it faster at the example,the example involve more about hardware example,i can't understand it very well.because of these unuseful example and practice,so the book is more theoretical,
so scan it and then get what you want get
i read it,when i have to accept a project "smartwave" ,whose maintainer have leave.
i constantly debug and find what and where i need.i used the way such as know the system,find bug from downstream,log the debug system and so on.so the book is useful,
but i metioned the soft developer,you can read it faster at the example,the example involve more about hardware example,i can't understand it very well.because of these unuseful example and practice,so the book is more theoretical,
so scan it and then get what you want get
December 11, 2011
For years my only recommendation to someone interested in the heuristics of problem solving was George Polya's "How To Solve It", but now I can cheerfully add Agan's "Debugging".
His nine common sense rules for successful computer program code and hardware troubleshooting and debugging are applicable to all fields of technical endeavor.
Highly recommended!
His nine common sense rules for successful computer program code and hardware troubleshooting and debugging are applicable to all fields of technical endeavor.
Highly recommended!
December 28, 2014
I'll bet that many of these rules are seen as common sense in the developer communities. As a programming student this book helped me view debugging as a process, rather than a "holy shit it finally works" moment. I recommend this book to all engineers, both the students and the ones in the industry.
January 25, 2016
Interesting to read a methodology around debugging. The book is well-organized entertaining and easy to read. I was quite pleasantly surprised the author managed to reduce the skill to nine short rules particularly when it sometimes can be a process that is difficult to explain. The examples were a bit dated and it helps to understand solid state electronics but the principles are sound.
August 20, 2014
Not a lot new here. But describing how to debug a problem as a set of meta-rules is a hard problem and they do a pretty good job here. Very light and lots and lots of war stories but aimed to be amusing and was at least somewhat amusing and fairly short. Worth reading.
Displaying 1 - 30 of 37 reviews