Pair programming and the mysterious role of the navigator

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.

Collaboration in Pair Programming: Driving and Switching

“…This indicates that the navigator was actively involved and understood the work of the driver as this is a precondition to take over control so effortlessly. This is consistent with the findings from Freudenberg et al [6,9] and Chong [7] who stated that driver and navigator work on the same level of abstraction and switch between these levels as a pair.…”

“…However, these role descriptions have been challenged by the results of recent studies [6,7,9] that show that driver and navigator do not think or act on different levels of abstraction. Freudenberg et al [6,9] conducted four one-week studies with experienced pair programmers in industrial settings.…”

“…Freudenberg et al [6,9] conducted four one-week studies with experienced pair programmers in industrial settings. They showed firstly that a significant amount of talk is at an intermediate level of abstraction and secondly that driver and navigator tend to work on the same level of abstraction.…”

“…Our study focuses mainly on the switching and driving behaviour of the developers, therefore we gathered very detailed data using video recordings of the PP sessions and analysed the data by coding these videos in a way that the results can be quantified as well. Most of the other studies [6,7,8,9,14] used observational data, audio recordings or self-reported data. Those data sources capture less detailed data about the switching and driving behaviour.…”

Exploratory Comparison of Expert and Novice Pair Programmers

“…They conclude that pair programming is highly collaborative, although the level of collaboration depends on the sub-task. In a follow-up study Bryant et al [9] report on data of 24 pair programming sessions. The authors observe that the commonly assumed roles of the navigator acting as a reviewer and working on a higher level of abstraction do not occur.…”