Candidate Talk: Debugging Reinvented: Asking and Answering Why and Why Not Questions about Program Behavior

Most software undergoes a brief period of rapid development, followed by a much longer period of maintenance and adaptation. As a result, software developers spend most of their time exploring a system’s underlying source code to determine the parts of the system that are relevant to their tasks. Because these parts are often distributed throughout a system’s modules, and because they can interact in complex and unpredictable ways, this process of understanding a program’s execution can be extremely difficult.

The primary cause of this difficulty is that developers must answer their questions about a system’s behavior by guessing. For example, a developer wondering, “Why didn’t this button do anything after I pressed it?” must form an answer such as “Maybe because its event handler wasn’t called” and then use breakpoint debuggers, print statements, and other low-level tools to verify the explanation. Not only is this process poorly supported by current tools, but worse yet, there are many potential explanations for a system’s behavior, so developers rarely formulate a valid explanation on the first attempt.

To address this problem, I present a new kind of program understanding tool called a Whyline, which allows a developer to select “why did” and “why didn’t” questions directly about the symptoms of a system’s behavior. In response, the Whyline determines which parts of the system and its execution are related to the symptom in question, while also identifying false assumptions the developer might have about what occurred during the execution of the program. By using this approach, developers need not guess about potential causes of program behavior:
they simply point to some perceptible feature of the faulty behavior and the system identifies the relevant code.

Early prototypes of the Whyline for a simplified educational programming language reduced debugging time by a factor of 8. I have since generalized the Whyline to support Java programs with textual and graphical output, inventing several new incremental algorithms to identify program-specific output, derive output-relevant questions, and answer questions about a variety of output. In a comparison of the Whyline to conventional debugging tools, developers with the Whyline found bugs with twice the success, twice as fast.