Thanks for the comments. I had a look at your poster and it is quiet simple and practical. Thanks for sharing. Debugging continues to consume significant efforts (and hence cost) among all Software Engineering activities. Following such rules and asking critical questions will benefit engineers who spend long hours in debugging.
I devoted a whole book, appropriately titled "Debugging" to the subject. It too is a lighter attempt to enable better debugging. But it does work -- all of the general guidelines I've seen are still covered by the 9 rules and their corollaries. So for example, Larry M.'s comment is covered well by rule 3, Quit Thinking and Look. The 9 rules are available on a poster from www.debuggingrules.com.
-- Dave Agans
Thanks for reading my blog. I liked your quote very much. The ability to see or visualize the right thing is very critical to debugging.
My Product Engineering Blog: http://www.mindtree.com/blogs/category/software-product-engineering
I once wrote an article on debugging that included an observation on how a good debugger operates. If I may be allowed to (probably mis)quote myself:
"A good debugger sees what is, not what he expects it to be, what he thinks it must be, or what he wants it to be".
Literally the developer is their own worst enemy when debugging a system. They know what it is supposed to do, so they come in with expectations that this is what it must be doing. This is why a different person sees bugs that a developer will miss.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...