‘Talking the talk’: Is intermediate-level conversation the key to the pair programming success story? S. Freudenberg (née Bryant), P. Romero, B. du Boulay IDEAS Laboratory, University of Sussex [email protected] Abstract One possible method of taming the complexity of software development may be to work collaboratively. Pair programming claims to provide benefits over In fact, one form of collaborative programming has and above those offered by a programmer working now been formalised as ‘pair programming’, one of the alone. In particular, a number of studies have core practices of the Extreme Programming (XP) suggested that pair programming improves software methodology. In pair programming, “all production quality. The literature speculates that the ‘driver’ (the code is written with two people working at one programmer currently typing in the code) and machine, with one keyboard and one mouse” (Beck, ‘navigator’ work together in a complimentary manner, 2000). and that the nature of these roles may be key in A wide range of studies have considered the realizing the reported benefits. Here we dispute two of benefits of pair programming in terms of its effect on these existing claims: (i) That the navigator providing the quality of the resulting software. These studies a ‘continual review’ of the drivers work and have taken place in both academic and commercial highlighting errors (i.e. acting as a reviewer); (ii) That environments. In the commercial arena two studies are the navigator is focused on a higher level of particularly note-worthy: Nosek (1998), who showed abstraction that the driver (i.e. acting as a foreman). that pair teams significantly outperformed individuals Our findings suggest that the key to the on program quality and Jensen (2003), who showed an success of pair programming does not lie in the error rate three orders of magnitude less for a project differences in behaviour or focus between the driver with pair programming than other similar projects. In and navigator. Rather, we suggest an alternative an academic environment, the most cited study is perspective (the “tag team”) and remark upon the probably that described in Williams, Kessler, proliferation of talk at an intermediate level of detail in Cunningham & Jeffries (2000) in which 13 university pair programmers’ conversations. This leads us to students worked individually on a project and 28 chose suggest that producing the type of talk necessary to to work in pairs. The findings showed that code work effectively together may itself be fundamental in produced by the pairs passed more automated tests realizing the reported improvements in software over four different programming exercises. It is, quality. however, possible that these findings might have been due to learning effects or the fact that the participants were free to choose whether or not to pair. For 1. Introduction example, more able students might have been more willing to work in pairs. Computer programming is a cognitively taxing task. Despite these reported benefits, the cognitive Not only is it difficult because of a lack of direct aspects of pair programming are seldom investigated manipulation (Blackwell, 2002) and a ‘product that no- and little understood. An ethnographic study by Sharp one can see’ (Perry, Staudenmayer & Votta, 1994) but and Robinson (2003) provides an insightful story of due to many other factors. These include complexity, XP in a commercial environment, but does not assess the need for a multi-layered, multi-dimensional model pair programming from a cognitive perspective. In fact capable of supporting mental simulations and the sheer there have been a number of calls for further amount of knowledge required, its suitable investigation of ‘the nature of the interactions that organisation and mechanisms for its access. underpin these results’ (Wiedenbeck, Ramalingam, Sarasamma & Corritore, 1999) and when and why pair reviewing the problem currently being worked on (the programming is effective (Chong et al., 2005). navigator)”. Beck (2000) also says that “While one The literature suggests two possible methods by partner is busy typing, the other partner is thinking at a which the programming pair may achieve these more strategic level” later describing this further as benefits. We have called these the ‘navigator as “One partner….is thinking about the best way to reviewer’ and the ‘navigator as foreman’. By implement this method right here. The other partner is ‘reviewer’ we mean that the navigator reviews the code thinking more strategically”. Hazaan & Dubinsky that the driver is typing in, pointing out any syntax and (2003) concur that “The one with the keyboard and the spelling errors. By ‘foreman’ we mean that the mouse thinks about the best way to implement a navigator thinks about the overall structure of the code- specific task; the other partner thinks more base and whether the code is solving the business strategically. As the two individuals in the pair think at problem for which it is intended. different levels of abstraction, the same task is thought Here we use data from four studies of commercial about at two different levels of abstraction at the same pair programmers to seek evidence of these two time”. realizations of the navigator role. We begin by outlining in more detail what is meant by the 3. Levels of abstraction ‘reviewer’ and ‘foreman’ and by clarifying how these These suggestions actually span two different have been related to ‘levels of abstraction’. In section 4 concepts, both of which are present in the wider we provide the background to our studies and in ‘psychology of programming’ literature. First, they section 5 we detail the methodology we have used. We delineate between two domains, the programming then present the results of our analyses, focusing on the domain and the problem domain; Second, they suggest ‘reviewer’ in section 6.6 and the ‘foreman’ in section that the programming domain may then be further 6.7. In the discussion that follows we present an defined using the model of a series of ‘levels of alternative perspective, that the driver and navigator abstraction’. form a kind of cognitive ‘tag team’. We also indicate The concepts of ‘domain’ and ‘level of abstraction’ the proliferation of an intermediate level of talk and appear rather interchangeably in the literature. For theorise about how it might be beneficial. We conclude example, Brooks (1983) suggests the existence of a set by summarising our theories, discussing its limitations of five ‘domains’ (problem, identifier, algorithmic, and suggesting future studies in this area. programming language and execution) and Pennington (1987) mixes abstraction and domain in her discussion of a detailed domain (of specific programming 2. The navigator as ‘reviewer’ and operations and variables), a program domain (of ‘foreman’ routines and files) and a real-world domain. Bergantz and Hassel (1991) also discuss programming as In their book on pair programming, Williams and requiring hierarchical models of abstract levels of Kessler (2003) refer simultaneously to both the functionality. reviewer and foreman when they state that ‘The Here we refer to the term ‘levels of abstraction’ to navigator…observe(s) the work of the driver, looking consider both level of granularity within the for tactical and strategic defects. Tactical defects are programming domain and a separation of program syntax errors, typos, calling the wrong method, and so domain from problem or ‘real world’ domain. We have on. Strategic defects occur when…what is done this in order to create a single scale and because it implemented just won’t accomplish what needs to be is clear that having first distinguished between problem accomplished’’. and programming domains it is only necessary to The ‘reviewer’ role is also alluded to in Wakes further delineate level of granularity in the (2002) suggestions that one navigator behaviour is programming domain in order to investigate the “The partner provid(ing) an ongoing quality boost: concepts of ‘navigator as reviewer’ and ‘navigator as review(ing)” and in describing a commercial pair foreman’. In our scale, the lowest level of abstraction is programming ‘experiment’. Jensen (2003) also states program syntax and spelling, and the highest is the that “The navigator review(s), in real time, the problem domain. information entered by the driver”. According to the literature it could be predicted that There are also further occurrences of the ‘foreman’ these foreman and reviewer roles imply working, and role in the literature. Dick & Zarnett (2002) suggest therefore verbalising, at different levels of abstraction. that “The first is responsible for the typing of code (the For example, when seeking evidence of the ‘reviewer’ driver); the second is responsible for strategizing and we would expect the navigator to verbalise at a very granular (or ‘low’) level of abstraction in discussions study of pair programmers so that ‘the cognitive about spelling and syntax, and not to simply wait for processes underlying productivity and quality gains their turn as driver to make corrections. For the can be formally mapped rather than speculated about’. ‘foreman’ role, we would expect the navigator to work While extra-pair communication (for example, at higher levels of abstraction, discussing the business discussion with a third party) may be an interesting problem the general layout of the code area of study, it has been excluded from this analysis. 4. Study background The methodology used for this work followed the framework for verbal protocol analysis set down by In line with calls for studies of programmers Chi (1997) in which protocols are produced, working in an industrial setting (**Cite Curtis**), the transcriptions are segmented and coded according to a analysis and results presented here are from four, one- coding schema, depicted in some manner and patterns week studies of commercial programmers working on are sought and interpreted. The coding derived is on-going tasks in their usual environment.