3.2.1 Pair programming
Pair programming [Williams and Kessler, 2000], a method by which the two co-located pro- grammers share a display while performing various programming tasks. The collaborators typically adopt the roles of driver (actual typing) and navigator (focusing on organisational activities and planning) while working. According to the proponents of pair programming, the method leads to higher quality programs in comparison with individual work. More generally, we take pair programming as a special case of collaborative problem solving, a process that involves coordination between participants and the construction of shared understanding. Pair programming is usually done with co-located programmers. However, spatially dis- tributed pair programming have been studied with satisfactory results showing that the distance factor can be neglected [Baheti et al., 2002]. Pair programming leads to high quality programs [Nüssli, 2011], hence a pair of expert programmers, working in a remote collabora- tive setting, could obtain a better understanding of a program as well.
3.2.2 Program comprehension as a problem solving task
Program Comprehension is central in many programming tasks, for example during software maintenance or software evolution, where programmers have to read and extend code that they did not necessarily produce themselves. Program comprehension is a special kind of problem solving. Like any problem solving task, program comprehension has a problem statement (to understand the given program) and a solution (the description of functionality of the program) and different approaches to get the solution. The main approaches are top-down and bottom-up. Top-down approach involves decomposition of the problem in sub-problems; and solving the sub-problems, while bottom-up approach involves integration of low-level details to come up with a solution.
Program comprehension is a goal-oriented, problem-solving task that is driven by preexisting notions about the functionality of the given code [Koenemann and Robertson, 1991]. It could be thought of a pattern matching at different levels of abstraction [Tilley et al., 1996]. The different abstraction levels help understanding a program at different levels, for example, at syntactical level programmers could understand the relation between different programming constructs and at semantic level they could relate different programming structures to their real world counterparts. The potential of eye-tracking in diagnosing the quality or the strate- gies of understanding relies on the assumption that understanding strategies are reflected by different ways to “read” the code.
3.2. Context
3.2.3 Program comprehension strategies
There are several strategies to understand a program, a top-down approach [Soloway and Ehrlich, 1984] consists of starting with a hypothesis about the program and then validating or “end marking” the hypothesis with the individual components of the program. A Bottom-up approach [Shneiderman and Mayer, 1979] starts from a series of code fragmentation and then assigns a domain concept to each fragment. An Iterative approach [Brooks, 1983] includes a “while” loop of top-down process, i.e., having a set of preexisting notions or hypothesis, their verification and modification, until everything in the program can be explained within the set of notions with which the iteration started. There are some more strategies that are a hybridisation of top-down and bottom-up [Letovsky, 1987, Von Mayrhauser et al., 1995]. These two strategies are used interchangeably during program comprehension as and when needed [Letovsky, 1987].
Letovsky [1987] proposed a typical set of mental models needed to understand a program which included specific functionality of a program, the way it had beed implemented and relationship among different parts of the program. Letovsky [1987] also emphasised that mental model for implementation consists of actions and data structures of a program. Under- standing the entities/data/variables and relationship amongst them inside a program was very important, in order to assign them a concept from the domain knowledge [Biggerstaff et al., 1994]. [Johnson and Soloway, 1985] advocated for having a programming plan to understand the program text (what was written?) and the program intent (why was something written?), and then divided the programming plan into two major parts “Variable plan” (how the data flow of the program worked) and “Control plan” (how were the different conditions related to each other). Johnson and Soloway [1985] then proposed the use of variable plan to understand the relation between program text and program intent.
3.2.4 Elicitations and program understanding
Pennington [1987] gave a special abstract program representation code (control flow, data flow, functional, state charts, condition-action table) to each explanation along with a spe- cial knowledge plan code. Each knowledge plan contained a different way to represent the functionality of the given program. For example, the control flow described how the compiler moves between different lines of the program; while the condition-action table listed all the conditions in the program and the how they effected the output of the program. This coding scheme lacked the sense of abstraction hierarchy in the explanation. Having an abstraction hierarchy in the codes is important to know the underlying cognitive (bottom-up or top-down or opportunistic) model of the explanation. Von Mayrhauser et al. [1995] pointed out the need to categorise the dialogues, with each category containing a cognitive significance. The categorisation used by Von Mayrhauser et al. [1995] was too detailed for a program having 100- 150 lines of code, as the authors mentioned in that the goal of comprehension, in their case, was software maintenance; for us it provided the basis of understanding through studying
Chapter 3. Pair Program Comprehension
the patterns of pairs with good understanding. Good and Brna [Good and Brna, 2004, 2003] gave a coding scheme that is free from program summaries. Their main focus was on finding the information structure produced; and not the underlying cognitive processes in program comprehension.
3.2.5 Expertise and program understanding
A bottom-up approach characterised novice programmers, while experts followed a top-down approach of generating a hypothesis and verifying it in most of the cases. While experts and novices might possess the same semantic knowledge, experts used their experience to make better use of knowledge [Kolodner, 1983].
In two different studies Bonar and Soloway [1983] and Koenemann and Robertson [1991] described the particular strategies for novice and expert programmers respectively. On one hand, Bonar and Soloway [1983] found that for the understanding of novices while loops sometimes become “while demons”. Moreover, novices had “conflicts” in the strategies to be applied for giving the “Natural Language Description” of a program. Novices tend to follow the “systematic execution” of the program and increase their chances to get stuck. Line by line understanding is typical in bottom-up integration of program functionality and is characteristic of lack of hypothesis [Bonar and Soloway, 1983].
On the other hand, Koenemann and Robertson [1991] found that experts applied the as-needed strategy, where they limited their understanding to only those parts of the program that they find relevant to a given task. Experts did not follow a predefined strategy to understand a program. For example, experts did not decide beforehand to understand a program in “top- down” or “bottom-up” manner. Experts tend to use both of them as and when needed. In another study, Koenemann and Robertson [1991] found that experts used a top-down strategy but, in case of a hypothesis failure a bottom-up strategy was used.