featureprogramming How Pair Programming Really Works Stuart Wray, Royal School of Signals air programming has generated considerable controversy: some developers Pair programming are enthusiastic about it, almost evangelical; others are dubious, even hostile. isn’t always However, a large factor in this controversy is that programmers label a wide successful, and variety of practices under the “pair programming” umbrella. Thus, before recent studies cast Pour community can sensibly discuss how pair programming works, we !rst need to es- doubt on the “driver- tablish exactly what it is. navigator” metaphor. As a dictionary de!nition, I’d say that pair at the keyboard, usually swapping over with a Four mechanisms programming is a technique in which two people phrase like, “No, let me show you what I mean.” can improve pair sit down, literally side by side, and write a pro- Jan Chong and Tom Hurlbutt con!rmed this gram at the same computer. When Kent Beck view of successful pair programming after spend- programming originally coined the term, he described two ing several months on an ethnographic study of performance. programmers working at different levels of ab- professional developers who use pair program- straction.1 Laurie Williams and Robert Kessler ming in their daily work.3 They found that pro- made this idea more concrete, using the meta- grammers tended to work together on the same phor of one programmer being the “driver” and facet of a problem almost the whole time and the other the “navigator.”2 In this metaphor, the swap between tactical and architectural levels as driver controls the keyboard and focuses on the a pair. Similar ethnographic studies by Sallyann immediate task of coding, and the navigator acts Bryant and her colleagues4 and Stephan Salinger as a reviewer, observing and thinking about more and his colleagues further con!rmed this.5 strategic architectural issues. Of course, not all attempts at pair program- My own experience as a developer using pair ming have been successful—Matt Stephens and programming is that it isn’t just a technique Doug Rosenberg, for example, reported unfa- where one person programs and the other per- vorably on their experiences.6 However, what son watches. Both programmers work closely to- they described is a caricature of the driver- gether, chatting the whole time, jotting down re- navigator metaphor, with one programmer !rmly minders of things to do, and pointing out pieces in control and the other sitting quietly, doing little. Share your of code on the screen. (One of the clichés of pair Such misunderstanding shows that we can’t take comments at http:// programming is that if you’re doing it right, your a claim that developers are pair programming at computingnow. screen should be covered with greasy !nger-marks face value; they might not be doing what experi- computer.org/wray. by the end of the day.) Programmers take turns enced and effective pair programmers actually do. 50 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/10/$26.00 © 2010 IEEE This kind of misunderstanding also casts They tested another group in the same way, but doubt on the many attempts to assess pair pro- encouraged the students to explain the textbook gramming’s effectiveness. (Tore Dybå and his out loud and “!ll in the gaps” for themselves. The An expert is colleagues provide a very nice summary of this self-explainers learned signi!cantly more than the experimental work.7) If the subjects of these ex- control group, and those who explained the most more likely periments did different things, can we really com- improved the most. The researchers also prompted to ask a deep pare their results? And if they weren’t doing what the students for their explanations; they weren’t just question, which successful pair programmers do in commercial left to their own devices. In particular, they were practice, can we apply their !ndings to commer- “prompted for further clari!cation by the experi- prompts the cial development? menter if what they stated was vague.”10 novel inference In this article, I advance four mechanisms This brings me back to an often-neglected as- prompted by my own experience of pairing in pect of the expert programmer theory. When we from the stuck both agile and non-agile development. These coined that term, we noticed that although real un- programmer. mechanisms explain a large part of what suc- derstanding wasn’t necessary on the listener’s part, cessful pair programmers do. Of course, this is a belief that the listener really was an expert seemed only the beginning: you might have experiences to signi!cantly improve the outcome (hence our that con!rm or contradict my suggestions. What choice of name). have I missed? I hope you’ll contribute to the dis- But why would believing that you were talk- cussion of these issues on the Web site (http:// ing to experts make any difference when they computingnow.computer.org/wray). didn’t need to understand your explanation? Re- cent work by Rod Roscoe and Chi showed that Mechanism 1: prompting questions seems to be the key.11 In their Pair Programming Chat study, one student (the tutor) explained material to Around 1980, as computer science undergradu- another student (the tutee). As expected, the tutor ate students at the University of Cambridge, my actually learned more than the tutee, but the ques- friends and I noticed a strange phenomenon that tions the tutee asked made a dramatic difference in we called expert programmer theory. When one the quality of the tutor’s explanations. Most ques- of us had trouble getting our programs to work, tions were shallow, and could be satis!ed by mere we’d describe the nonfunctioning state of our code repetition of facts, but some questions were deep to each other over coffee. Quite often, we’d real- and often prompted deep answers that included ize in a "ash what was wrong and how to solve novel inferences or self-monitoring statements. it. These epiphanies were quite independent of the So perhaps this is how expert programmer the- other person having any real understanding of our ory really works: an expert is more likely to ask a problems—the listener often seemed little wiser deep question, which prompts the novel inference about the subject. from the stuck programmer. It also seems possible Since then, I’ve found this phenomenon is well that merely thinking that you’re talking to an ex- known to professional developers, and sometimes pert—or pretending—will help the stuck program- described in textbooks and research papers. For mer produce the sort of deep questions that experts example, Brian Kernighan and Rob Pike recom- have asked them in the past. mended explaining problems aloud, even to a As an explanation for expert programmer the- stuffed toy,8 a practice that John Sturdy called the ory, this is almost satisfactory, but is student learn- rubber-plant effect.9 Part of pair programming’s ing a good analogy for what happens to stuck effectiveness is presumably due to this effect be- programmers? After all, the students in these ex- ing continually triggered: as one programmer gets periments had to master basic science, and their ex- stuck, the back-and-forth chat serves to unstick planations helped them work out what they didn’t them in the same way as solo programmers talk- understand. Stuck programmers must already have ing about their problems out loud. However, this all the information somehow hidden in their heads raises the question of whether any type of speak- and then realize the answer in a moment of epiph- ing will help or whether something speci!c is any. How’s that possible? needed. It’s widely accepted that cognitive abilities are Research on “self-explanation” by Michelene divided into a variety of largely separate mental Chi and others throws some light on this ques- modules, each dealing with a different ability tion. Chi and her colleagues described a study that such as intuitive grasp of small numbers, predict- tested a control group of students before and after ing other people’s actions, facial recognition, and 10 they received a textbook explanation to read. so on. Less well known is the role of the language January/February 2010 IEEE SOFTWARE 51 module in integrating other modules’ knowledge. each other should be most productive of all. Experiments by Linda Hermer-Vazquez and her What we colleagues on integrating knowledge about ge- Mechanism 2: Pair ometry and color12 and by Ashley Newton and Programmers Notice More Details notice depends Jill de Villiers on false-belief reasoning13 showed Research on change blindness and inattentional on what we that adults perform as poorly as young children blindness illustrates something that stage magi- expect to see when their linguistic abilities are occupied with cians have known for a long time: if we don’t know a verbal shadowing task. The language mod- what to look for, we can stare right at it and still and what we ule seems crucial to combining knowledge from miss it. What we notice depends on what we ex- unconsciously other modules. pect to see and what we unconsciously consider This isn’t to say that we integrate the outputs salient. So, although successful pair programmers consider of several mental modules by talking to ourselves. will concentrate mostly on the same things, they salient. Rather, Peter Carruthers suggested that because might notice different things. speech is uniquely both an input and output brain Research on change blindness shows that peo- medium, the language module is the only one ple are remarkably poor at detecting changes, not with a strong connection to all the other mod- only in 2D images under laboratory conditions but ules.14 The mechanisms underlying the logical in real-life situations such as noticing the substitu- form of language might thus be redeployed at a tion of one person with another.15 It appears that level beneath conscious awareness to integrate in- people remember something they saw as belonging formation from other modules.