Some troubleshooting tips..

Dave DeFord

nerds. It's a book that is really written for software folks but it also looks like it would apply to almost any type of troubleshooting.


author: David J. Agans


pages: 192


publisher: Amacom


rating: 9


reviewer: David A. Wheeler


ISBN: 0814471684


summary: A classic book on debugging principles

Since the whole book revolves around the nine rules, it might help to understand the book by skimming the rules and their sub-rules:

1. Understand the system: Read the manual, read everything in depth, know the fundamentals, know the road map, understand your tools, and look up the details.

2. Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs, don't trust statistics too much, know that "that" can happen, and never throw away a debugging tool.


3. Quit thinking and look (get data first, don't just do complicated repairs based on guessing): See the failure, see the details, build instrumentation in, add instrumentation on, don't be afraid to dive in, watch out for Heisenberg, and guess only to focus the search.


4. Divide and conquer: Narrow the search with successive approximation, get the range, determine which side of the bug you're on, use easy-to-spot test patterns, start with the bad, fix the bugs you know about, and fix the noise first.


5. Change one thing at a time: Isolate the key factor, grab the brass bar with both hands (understand what's wrong before fixing), change one test at a time, compare it with a good one, and determine what you changed since the last time it worked.

6. Keep an audit trail: Write down what you did in what order and what happened as a result, understand that any detail could be the important one, correlate events, understand that audit trails for design are also good for testing, and write it down!

7. Check the plug: Question your assumptions, start at the beginning, and test the tool.

8. Get a fresh view: Ask for fresh insights, tap expertise, listen to the voice of experience, know that help is all around you, don't be proud, report symptoms (not theories), and realize that you don't have to be sure.

9. If you didn't fix it, it ain't fixed: Check that it's really fixed, check that it's really your fix that fixed it, know that it never just goes away by itself, fix the cause, and fix the process.

I found the above at

http://books.slashdot.org/books/04/02/21/228241.shtml

for those that are interested in the details and the discussion.

Just thought it might be of interest to some folks here. Disclaimer - I haven't read this book it just looks like it might have some good troubleshooting hints for this industry even though it is written for software debugging.