Pair Programming and the Mysterious Role of the Navigator Sallyann Bryant, Pablo Romero and Benedict du Boulay IDEAS laboratory, University of Sussex, UK s.bryant@sussex.ac.uk Abstract Computer programming is generally understood to be highly challenging and since its inception a wide range of approaches, tools and methodologies have been developed to assist in managing its complexity. Relatively recently the potential benefits of collaborative software development have been formalised in the practice of pair programming. Here we attempt to ‘unpick’ the pair programming process through the analysis of verbalisations from a number of commercial studies. We focus particularly on the roles of the two programmers and what their key characteristics and behaviours might be. In particular, we dispute two existing claims: (i) That the programmer who is not currently typing in code (“the navigator”) is constantly reviewing what is typed and highlighting any errors (i.e. acting as a reviewer); (ii) That the navigator focuses on a different level of abstraction as a way of ensuring coverage at all necessary levels (i.e. acting as a foreman). We provide an alternative model for these roles (“the tag team”) in which the driver and navigator play much more equal roles. We also suggest that a key factor in the success of pair programming may be the associated increase in talk at an intermediate level of abstraction. Keywords: Pair programming, verbal protocol analysis, extreme programming. 1. Introduction Computer programming is widely considered a highly complex task. A number of reasons have been suggested for this. For example, Blackwell (2002) reports that programming is hard because of the lack of direct manipulation and the use of a notation to represent abstraction. Similarly, Pennington, Lee & Rehder (1995) discuss the difficulties involved in maintaining several levels of information at the same time. They claim that the “major problem for programmers is to coordinate fundamentally different problem spaces”. Thus highlighting the complexity involved in working in both the highly structured, logical and constrained domain of the computer program and the fundamentally messy real world. While they focus on the problem and design domains, it may be argued that even in the programming domain, the programmer may need to work at a number of different levels of abstraction, from considering the structure of the code of the system as a whole to the syntax of the command that is currently being typed in. In fact, Brooks (1983) describes the programming task as “constructing mappings from a problem domain, possibly through several intermediate domains, into the programming domain”. It has also been reported (Petre & Blackwell, 1999) that experienced programmers maintain very complex, “dynamically stoppable” mental models of the programs they are working on which may help to manage this complexity.