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.
NASA's Orion Flight Software Production Systems Manager Darrel G. Raines joins Planet Analog Editor Steve Taranovich and Embedded.com Editor Max Maxfield to talk about embedded flight software used in Orion Spacecraft, part of NASA's Mars mission. Live radio show and live chat. Get your questions ready.
Brought to you by