8.7 Explain the problem to someone else 213
Table 8.2 shows another standard approach to describing a situation or
problem. The focus here is on the difference between the normal or
expected situation and what actually happened.
Questions about Differences
What (conditions, activities, components)
When (status, schedule, process)
Where (physical location)
How (omitted, extra, or out-of-sequence action)
Who (actors, observers, supervisors)
Explain the problem to someone else
This heuristic is helpful when you have used up the hypotheses generated
by the other heuristics. If you can't articulate the problem, you don't know
enough about it yet. Thus, this heuristic isn't as valuable early on in the pro-
cess of diagnosing a bug.
Communicating forces us to organize our thoughts so that the other
person will understand. Don't tell the other person your conclusions or the
hypotheses that you have already disproved. This will distract your listener
and lead him or her down the same dead-ends you have already followed.
Stick to your observations. After you have explained the facts, ask for the
other person's hypotheses.
The other person won't necessarily share your internalized assumptions,
and you will have to explain them to make sense of the problem. New
hypotheses generated using this heuristic are often related to things you
have been assuming that the other person doesn't assume.
As an alternative, have someone else explain your program to you. This
is another way to get false assumptions out of the way. Try to create new
hypotheses based on the reader's interpretation of your program.
I Chapter 8