This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Bug Between Keyboard and Chair
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
James Bach has written a practical, useful, excellent entry on investigating intermittent bugs (or other types of problems, but us software types are more likely to be interested in investigating software defects).
A lot of the advice applies not just to intermittent problems, but to persistent ones as well: the ones that stubbornly resist our best efforts to solve them. For instance, bugs that you stay up all night chasing, fixing one thing after another, each time thinking you've nailed it but seeing it pop up again, undefeated, like a jack in the box.
James' advice is in crisp checklist style, so it will come in handy as a way to jog your brain if you ever come across one of these pesky problems. Note how many of the items relate not so much to the "objective" definition of the problem, but to the role of the observer - that's you.
Most of the time, we approach debugging from a purely objective standpoint. For instance, we use tactics like the binary chop: delete half the code, if the bug still occurs it must be in the remaining half, otherwise it was in the deleted half. (Works fine, except when the bug stops occuring if you delete either half; or, more irritating still, keeps occurring whichever half you delete.) We list hypotheses and devise tests that which invalidate them, and so on.
These are all useful tactics. But problems don't exist in isolation - wherever there's a problem, there must be a problem-solver. In many situations that I recall, an intermittent or a persistent problem directly had something to do with my efforts to solve it.
(If you have war stories of that kind to share, feel free to use that "Comments" link...)
Previous Topic
