This page presents comments, ideas,
and war stories from you and your fellow debuggers. If you
have some comments, ideas, and/or war stories to share, please go to
the "Send in your stories" page. Stories may be edited -- and our apologies to those of you who've been waiting around for me to post your stories!
"Look at the simple stuff
first" from Quentin Lewis.
"A lazy graphics card"
from Eddy Carroll.
A fine software demonstration of "Stimulate, don't simulate" (and "check
the plug") from Frederick Hill.
"Find the feather", also
from Frederick Hill. Here's an application of the debugging rules
to playing an adventure game...
"Dust off those floppies",
from Brian Aust. The real scoop on floppy disks.
up to the problem", from Don Borowski. Here's a case where measuring
while it wasn't failing gave misleading results.
few stories on the theme of Check the Plug", from Nick Coghlan. Read
those appnotes and call that vendor.
"Bargain parts", from Mark. Check the Plug and Get a Fresh View are both nicely illustrated.
Tom Culliton emphasizes that Check the Plug often means checking the user's configuration, and then adds that you probably want to check the documentation, too -- many misconfigurations are caused by bugs in the manual. I agree -- this is akin to the oil on the floor problem, where the real source is not enough bolts, which causes vibration, which causes the fitting to shake loose, which causes the oil leak.
Steve Meirowsky has Checked the Plug and found bugs in compilers, linkers, locators, and assemblers. Of course, he has documented and reported every one. I'd like to think these issues are rare, but I once had an IDE whose symbol browser somehow caused the compiler to ignore the last line of the file -- sometimes. If every user has just one compiler bug, that's a lot of bugs.
© 2002 by David J. Agans
All content on this site is copyrighted.
You have permission to download, print, and otherwise
distribute the Debugging Rules poster, providing you use it in its
entirety with no modifications whatsoever.