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

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.

Aidez d'autres clients à trouver les commentaires les plus utiles   Ce commentaire vous a-t-il été utile ?

Signaler ce commentaire

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.

Aidez d'autres clients à trouver les commentaires les plus utiles   Ce commentaire vous a-t-il été utile ?

Signaler ce commentaire

His first rule is "understand the system", another way to say "don't assume" or "read the manual". [His comments on "a politician" tells me he should follow rule #1 (p.18).] Sometimes the constraints of time and money will not let you capture enough information; management will set the rules and schedules.

The "quit thinking and look" rule says that facts should drive theories (like in criminal detection). Making a list of probable causes can be a guide to research. Page 54 tells of a bug in "one small, simple software routine". Is code inspection passe? Page 65 tells of a light not going on. Based on MTBF, its more likely the light bulb than the switch. But don't overlook the possibility of the connection at the receptacle.

"Divide and Conquer" would be better phrased as "narrowing the search" for a faulty component in a planned, logical manner. Changing one thing at a time advises against trial and error, or guessing at the solution. Keeping track of all changes allows narrowing the search, and any possible interaction with an earlier change.

"Check the Plug" suggests using a PRINT statement that works all the time, not just for a certain event. This is not practical advice in my experience! You should test the tool before using it for testing; recalibration is always good. "Get a Fresh View" is another way to restate the problem. When doing this you may suddenly realize what you've overlooked. Often someone has come across the same or similar problem. It can also be good politics to delegate responsibility.

Page 125 describes the classic "dirty gas filter" syndrome. Consider getting the gas lines blown out. A locking gas cap is one way to prevent this; don't overlook sabotage as a cause. "In the old system we knew how to crash it so they'd send us out on break." Chapter 11 recommends testing a fix by removing it to prove the change. This rules out any random differences; except when its obvious (p.128). Some problems do go away by itself. I once worked on a serially-reusable on-line program. After I made it reentrant (so it didn't modify the code) a lot of strange bugs just disappeared.

Chapter 13 gives a number of examples using the rules. The touchpad problem could have been avoided with either code inspection or programming standards. Or a better compiler? Chapter 14 tgells how the rules apply to a Help Desk. The last chapter suggests how to use this book at work or in school. But if your job resembles Dilbert's, bring your resume up to date (the tenth rule?).

Aidez d'autres clients à trouver les commentaires les plus utiles   Ce commentaire vous a-t-il été utile ?

Signaler ce commentaire