Debugging by Thinking

8.7 Explain the problem to someone else 213

Table 8.2

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)

Difference/

Change

Effect

8.7

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