Notes on “Debugging by asking questions about program output”

June 25, 2009

Debugging by asking questions about program output: Andrew Ko

A key to the difficulty of debugging is the difficulty of mapping conceptual-level questions about program behaviour to concrete questions about code.

This paper introduces the Whyline.

Key motivators: Developers form multiple false hypotheses of failure causes. Unchecked false hypotheses eventually cause problems. Developers break good code while ‘fixing’ false hypothesis causes.

Therefore: Allow developers to specify incorrect output. Correct incorrect assumptions early. (Although it isn’t clear that the assumption-correction is implemented in Whyline or implementable.)

To build a whyline:

  • Outputs are defined at a conceptual level and must be recorded. (e.g. Paint commands)
  • Developers restrict the domain of their questions in several ways:
    • Type of causality (Why or why didn’t)
    • Scope of question’s objects
    • Relative to events
    • Features of output types
  • Analyze causality of processing leading to the incorrect output
  • Aggregate chains of causality that executed in similar contexts
%d bloggers like this: