Debugging another programmer's code

Waddington and Henry [23] considered the situation in which one programmer writes a program and the other has to debug it. They proposed a model of the debugging process which revolved around three ideas: the predicted program behaviour, the actual program behaviour, and the intended program behaviour. They suggested that before a programmer can start to make predictions about the way the program will operate, some insight is required into the intentions of the original programmer.

To verify this model, they set up an experiment in which experienced programmers were given a small program (concurrent quicksort) to comprehend. In the first phase of the experiment, a version of the program that contained two bugs was presented to the programmers, and they were asked to debug it. During this phase, the programmers constructed their mental model of the program. In the second phase, the programmers were asked questions about the actual behaviour of the program, and about the original intentions of the programmer. Waddington and Henry discovered that there was no significant difference in the time taken to answer these two types of questions. They concluded that the programmers had obtained as much information about intentions as actuality, and that they had used their conception of the intentions of the programmer as part of their debugging strategy. The important conclusion for my purposes is that the navigator needs to display some indication of the programmer's thought processes, as well as the specific implementation that it led to, in order to improve programmer efficiency. The code is not the best way to express this kind of information, and so my navigator seeks to create a graphical means to convey it instead.