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.
Replay available now: A handful of emerging network technologies are competing to be the preferred wide-area connection for the Internet of Things. All claim lower costs and power use than cellular but none have wide deployment yet. Listen in as proponents of leading contenders make their case to be the metro or national IoT network of the future. Rick Merritt, EE Times Silicon Valley Bureau Chief, moderators this discussion. Join in and ask his guests questions.