Three Question About Each Bug Found

Fix a bug

Look at the code, fully understand how code works and try to find out which part might went wrong.

Start with the observable facts and work backwards, asking why repeatedly, until I can describe the pattern that underlies the bug.

"It blew up because subscript J was out of range."
"Why?"
"J was 10 but the top array subscript is only 9."
"Why?"
"J is a string length, and the array origin is 0, so the last character in a string of length 1 is index 0."

Ask three questions

1. Is this mistake somewhere else also?

Find out pattern of a bug, think that any other place might also have this kind of problem.

"Where else do I use a length as a subscript?"
"Do all my arrays have the same origin?"
"What would happen for a zero length string?"

Try to descibe a bug in general terms.

"The starting offset plus the length, minus 1, is the ending subscript.. unless the length is zero."

It's more productive to fix several bugs that is similar to this one.

2. What next bug is hidden behind this one?

What will happen after this bug is fixed. Is it possible that statements after failing lines also has another bug, it's not found due to never executed?

Read following lines of code to make sure eveyting will be fine.

"Would this next statement work?"
"Are there combinations of features I've never tested?"
"Can I make all the error messages come out in test?"

Making change of the code might has other impact that causes another bug.

"If I just subtract one from J, the move statement later will try to move -1 characters when the string length is 0."

If too much modifications are made due to fix a bug, consider carefully whether adding fix is the right thing to do, or it's time to re-design and re-implement.

3. What should I do to prevent bugs like this?

Think when the bug is introduced, is it possible to eliminate this kind of bug in developemnt lifecycle?

"The design is OK; I introduced this bug in coding."

Examine reason for the bug in detail. Think about how to prevent this bug.

"Separate data types for offset and length would have caught this error at compilation time."
"Each text item could be output with a macro which hides the subscripting calculation. Then I can figure this out just once."

Don't be satisfied with glib answers. Suppose explanation for a bug is, "I just forgot."

How can the process be changed so I don't need to remember?

The language can be changed so that the detail I omitted is completely hidden, or my omission is detected and causes a compiler diagnostic. I might use a language pre-processor for this problem domain, or a clever editing tool which fills in defaults, checks for errors, or provides hints and rapid documentation. The bug may be a symptom of communication problems in the programming team, or of conflicting design assumptions which need discussion.

Consider the way bug is found, and ask myself how it could have been found earlier.

Is writing test suitable?
How could test be made more air-tight?
Could test be generated automatically?
Could in-line checking code be added that would trap errors all the time?

"I should try a zero length string in my unit tests."
"I could enable subscript checking and catch this sooner."

Systematic methods and automated tools for compilation, build, and test are always worth creating. They pay for themselves quickly, by eliminating long debugging and fact-finding sessions.

Development

During design and implementation review, each comment I get can be treated with the three questions. Review comments are the result of an underlying communication process which I can improve. If I feel that a reader's comment on a specification is wrong, for example, I might ask what kept my document from being understood, and how I might communicate better with the reviewer.

Design and code inspections are a powerful means of finding many bugs. I can ask the three questions about each defect discovered in the inspection process. The first two questions won't turn up many new bugs if the inspection process is thorough, but the third question can help find ways to prevent future bugs.