An alibi has three components: time, place, and corroboration. A program that has side effects has no alibi for the time a problem occurred or the place it occurred. The debugging equivalent of an alibi is the assertion that a given system component can’t be the cause of a problem.
Exercising curiosity is one way we leverage the labor of finding the cause of a defect. We use this curiosity when we investigate potential related problems, even before they’re reported.
Facts aren’t complete without qualification. Use the reporter’s questions—who, what, where, when, how often—to qualify the facts of a defect report to make it useful.
If you believe that a phenomenon observable by the human senses is both true and false, you’re going to have a hard time with the scientific method. All classical reasoning methods depend on this principle.
The trick to enumerating possibilities is knowing when you’re done. You can enumerate possibilities by using the principle of noncontradiction and a binary tree.
There are lots of good ways to organize a search for the explanation of a defect, but few programmers use any system. Some possible approaches include the black box, the scientific method, the reporter’s method, and the tester’s method.
In many disciplines, we’re told, don’t make assumptions. Unfortunately, this is easier said than done. You can follow a method that minimizes the effects that assumptions have on your search.
If you’re working with a large amount of data, display it visually so that your brain can recognize larger patterns you might not recognize from looking at numerical values. Color-coding items in a listing is an effective way to make your brain pick out patterns.
Use one of several diagram types to show how a defect could occur.