XP and pair programming practices

Over the past ten years or so Extreme Programming has been slowly gaining acceptance as a potentially beneficial technique both in the commercial and academic worlds. Here we review the existing literature to attempt to gain insight into the practice of pair programming across both educational and commercial context. We begin by considering the pair programming team and the environment in which pairing takes place. We then review a number of studies aimed at measuring the costs and benefits of programming in a pair, particularly in terms of the quality of the software produced. Finally we discuss the potential cognitive benefits of pair programming and consider when and where its use might be most appropriate. 1 Extreme Programming Extreme programming is a methodology that has been slowly gaining acceptance and interest within the programming community over the last ten years. It is seen as an antidote to the large, up-front design methodologies commonly found within the software industry. Extreme Programming (or ‘XP’ as it is commonly known) stemmed from the working practices of a team of programmers working for Chrysler on a payroll system project known as ‘C3’. This team is said to have amplified the working practices that they found useful and enjoyable, and dropped those that they did not. XP falls under the umbrella term of ‘agile methodologies’. According to the Agile Alliance (www.agilealliance.org), an agile approach is one that values: “Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan”. As such, XP focuses on short development cycles with regular delivery of the new versions of software to the customer. In the most recent edition of Beck’s ‘white book’ on XP (Beck and Andres 2004) there are thirteen main or ‘primary’ practices and eleven ‘corollary’ practices. The main practices mainly relate to either team working (sit together, whole team, energised work, pair programming), communication (informative workspace, stories), project management (weekly cycle, quarterly cycle, slack), or programming practices (10 minute build, continuous integration, test-first programming and incremental design). Here we consider the practice of pair programming. 2 Pair Programming Pair programming has been defined as ‘two people working at one machine, with one keyboard and one mouse (Beck 2000). Within the extreme Programming framework, a pair is not usually fixed, that is, a programmer does not tend to work with the same partner all the time. More usually, a pair will work together for the duration of a single task. While some projects empower the programmers themselves with responsibility for deciding when to change pair, others enforce rotating pairs on a regular basis. 2.1 The driver and navigator roles The terms ‘driver’ and ‘navigator’ describe the role of each programmer. These roles are by no means fixed, a programmer may change roles several times within a programming session. The driver is the programmer who currently has control of the keyboard, while the navigator contributes to the task verbally and by other means. The navigator role could be considered something of a mystery. Some suggest that the navigator provides a constant design and code review, others consider him/her to be working at a higher level of abstraction than the driver (Hazzan and Tomayko 2003). This could also be described as the driver working tactically while the navigator works strategically (Williams and Kessler 2003). 2.2 The pair programming team Pair programmer generally takes place within the larger context of a programming ‘team’. A number of studies have considered the environment within which pair programming takes place. In particular, Sharp and Robinson (2003) focus on XP in their ethnographic work, providing useful insights into what it means to be a member of an XP team in a number of different commercial companies. Kessler and Williams (2003) consider pair programming as providing a form of ‘legitimate peripheral participation’ (Lave and Wenger 1991). Here, a novice programmer can learn the ‘craft’ of programming by working as part of a programming pair, playing a useful but controlled part in the production of software while being immersed in the project environment, in which (s)he can learn through observation. Similarly, Bryant, Romero et al. (2006) discuss the advantages of the pair’s conversation making their work visible to others on the team. They cite occasions where overhearing has resulted in advice and guidance from others outside the pair, or indeed, where pairs have been reformed according to whom on the team is best equipped to work on the task at hand. 2.3 The pair programming environment Of course, pair programming does not happen in a vacuum. In fact, pair programming has been shown to “take place in the context of a rich environment of artifacts and talk” (Bryant, Romero et al. 2006) where tools created for individual use are often re-appropriated by programming pairs, for example the mouse and keyboard are subtley used to help smooth driver-navigator role exchange. In addition, novel artefacts like cuddly toys are reported as used for informal locking mechanisms when integrating new code onto the test machine (Sharp and Robinson 2003; Bryant, Romero et al. 2006). 2.4 The potential benefits of pair programming A number of studies have considered the effectiveness of pair programming. While some have looked at team morale and attitude towards pair programming (Benedicenti and Paranjape, 2001; Rumpe and Schroder, 2002; Pulugurtha, Neveu et al., 2002; Johnson, Mao et al., 2003), the majority of studies tend to consider whether projects with pair programming show improved quality or speed (e.g. Canfora, Cimitile et al., 2005). Here we consider studies which have attempted to identify the extent to which programming in pairs affects the quality of the resultant software in commercial and academic environments. 2.4.1 The Pair Programming Student A number of studies have found pair programming useful academically (e.g. Macias 2002; Noll and Atkinson 2003; Tessem 2003). Probably the most cited study aimed at assessing this is the study described in Williams, Kessler et al. (2000). In this between subjects study 13 university students chose to work on a project individually while 28 other students worked in pairs. The findings showed that code produced in pairs passed more automated tests over four different programming exercises as shown in Table 1. Exercise Individual Pair Program 1 73.4 % 86.4 % Program 2 78.1 % 88.6 % Program 3 70.4 % 87.1 % Program 4 78.1 % 94.4 % Table 1. Percentage of tests passed by individually or pair coded programs Williams et al Nevertheless, one might question the extent to which can it be ascertained whether the two groups were in fact comparable. It is possible that the more successful students might be more likely to have insight into the advantages of collaborative working, or were more aware of their strengths and weaknesses, and therefore be more likely to volunteer for pair programming. Similarly it is possible that when working in pairs the most able student is doing most of the work, therefore it may not be appropriate to compare a pair score with an individual score, but might be more useful to compare the score of a pair working collaboratively with the highest score of a randomly selected ‘pair’ of students working individually. Finally, given that the pairs were students learning affects should also be taken into consideration. 2.4.2 The Pair Programming Practitioner There are also a number of positive studies concerning commercial pair programming (see Benedicenti and Paranjape 2001; Deias, Mugheddu et al. 2002; Rumpe and Schroder 2002; Ambu and Gianneschi 2003) Lui and Chan (2003) performed experiments with experienced software developers. In their second experiment participants took algorithm-style aptitude tests on their own and in pairs. In pairs 85% of the responses were correct, compared to only 51% when working alone, however one might question the extent to which this task is comparable to an increase in software quality in a commercial computing environment. This result also underlines some of the issues raised above with regards to student pairs. A further study by Nosek (1998) considered fifteen full-time, experienced software developers working on challenging problems in their usual working environment. The report gives a clear and reliable definition of how quality was measured (a score of 0-2 for readability and a score out of 2 for each of 3 output requirements). Inter-grader reliability was 90%. The results showed that pair teams significantly outperformed individuals on program quality. Whilst not stated explicitly in the documentation, one can assume that the participants were not already experienced in pair programming, as Nosek (1998) states that they ‘were somewhat sceptical of the value of collaboration...and thought that the process would not be enjoyable’. This suggests that results were significant despite the required change in practice for those working in pairs. Finally, Jensen (2003) describes an experiment that took place in an organisation developing a complex real-time systems in Fortran. A single project trial of pair programming produced code with a 127 percent gain in productivity and an error rate three orders of magnitude less than those on similar projects. The programmers rated the pair designed code as ‘better quality’, although there is no clear definition of what this referred to. Despite the study not being a direct comparison with an alternative project, the development environment and methodology were the same as the other projects, and the experience of the team was considered ‘about average’ for the organisation. Taken as a group, these studies almost unanimously support the