How Pair Programming Really Works
Upcoming SlideShare
Loading in...5
×
 

How Pair Programming Really Works

on

  • 615 views

As a dictionary definition, it is said that pair programming is a technique in which two people sit down, literally side by side, and write a program at the same computer. It is also coined as, two ...

As a dictionary definition, it is said that pair programming is a technique in which two people sit down, literally side by side, and write a program at the same computer. It is also coined as, two programmers working at different levels of abstraction.

Statistics

Views

Total Views
615
Views on SlideShare
615
Embed Views
0

Actions

Likes
1
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

How Pair Programming Really Works How Pair Programming Really Works Document Transcript

  • feature programmingHow Pair ProgrammingReally Works Stuart Wray, Royal School of Signals P 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 our community can sensibly discuss how pair programming works, we first need to es- doubt on the “driver- tablish exactly what it is. navigator” metaphor. As a dictionary definition, 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 confirmed 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 confirmed 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 firmly 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 finger-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 SOFT WARE Published by the IEEE Computer Society 0 74 0 -74 5 9 / 10 / $ 2 6 . 0 0 © 2 0 10 I E E E
  • This kind of misunderstanding also casts They tested another group in the same way, butdoubt on the many attempts to assess pair pro- encouraged the students to explain the textbookgramming’s effectiveness. (Tore Dybå and his out loud and “fill in the gaps” for themselves. The An expert iscolleagues provide a very nice summary of thisexperimental work.7) If the subjects of these ex- self-explainers learned significantly more than the control group, and those who explained the most more likelyperiments did different things, can we really com- improved the most. The researchers also prompted to ask a deeppare their results? And if they weren’t doing whatsuccessful pair programmers do in commercial the students for their explanations; they weren’t just left to their own devices. In particular, they were question, whichpractice, can we apply their findings to commer- “prompted for further clarification by the experi- prompts thecial 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 stuckboth 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 seemedonly the beginning: you might have experiences to significantly improve the outcome (hence ourthat confirm 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 theycomputingnow.computer.org/wray). didn’t need to understand your explanation? Re- cent work by Rod Roscoe and Chi showed thatMechanism 1: prompting questions seems to be the key.11 In theirPair Programming Chat study, one student (the tutor) explained material toAround 1980, as computer science undergradu- another student (the tutee). As expected, the tutorate 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 inwe 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 satisfied by merewe’d describe the nonfunctioning state of our code repetition of facts, but some questions were deepto each other over coffee. Quite often, we’d real- and often prompted deep answers that includedize in a flash 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 aproblems—the listener often seemed little wiser deep question, which prompts the novel inferenceabout 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 expertsexample, 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 stuckeffectiveness 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’tthem in the same way as solo programmers talk- understand. Stuck programmers must already haveing about their problems out loud. However, this all the information somehow hidden in their headsraises the question of whether any type of speak- and then realize the answer in a moment of epiph-ing will help or whether something specific 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 mentalChi and others throws some light on this ques- modules, each dealing with a different abilitytion. 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, andthey received a textbook explanation to read.10 so on. Less well known is the role of the language January/February 2010 I E E E S O F T W A R E  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 Programmers Notice More Details notice depends ometry and color12 and by Ashley Newton and 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 a verbal shadowing task. The language mod- cians have known for a long time: if we don’t know 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. The logical form to a particular mental category, then fail to notice must be able to represent objects with properties substitution by another member of that category. derived from several modules because this is the A large portion of experts’ proficiency is probably basis for noun-phrases in speech. in their more detailed and extensive array of men- As programmers, we clearly use visual imagi- tal categories in their particular fields.16 Research nation to help design and debug our programs on inattentional blindness has similarly shown that (although the diagrams we use bear little rela- when our attention is focused on a particular task, tion to our programs’ texts). This visual informa- we can miss something that would otherwise be tion can be spread across several mental modules, so obvious that it would just pop out. For exam- and the other information we require to under- ple, it might seem unlikely that people would miss stand our programs can be in yet other modules. a woman in a gorilla suit walking into the shot in For example, it seems that our understanding of a video, but that’s what half the subjects did in a object-oriented (OO) programs is supported by study by Daniel Simons and Christopher Chabris.17 the folk psychology module that supplies intu- (They’d been instructed to pay close attention to an- itions about other people’s actions. (We think of other aspect of the video.) objects as having intentions, wanting to do things, So, two people programming together won’t and sending each other messages.) We therefore have the same prior knowledge or categorization: need to integrate information from separate mod- one will presumably spot some things faster and ules when thinking about our programs. Why the other different things faster. Where their rate of can’t we always integrate it straightaway? working is limited by the rate they can find things Carruthers suggested that we must rely on the by just looking, two heads must be better than one. language module posing the right question and And in fact, one of the earliest observations that that the other modules don’t usually present in- people make when they start to pair program is that formation spontaneously. However, when we the person who isn’t typing code always picks up ty- hear the right question, our brains make the nec- pos quicker: “Oh, you’ve left out the comma here.” essary information available, and the language Of course, the compiler would pick up such module can then perform rudimentary inference small slips easily, so in this case the early catch and draw the obvious conclusions. Carruthers isn’t very important. However, it’s crucial to catch suggested that the key is posing a question that’s problems early when the slip is more subtle—for “both relevant and fruitful.”14 The right question example, if the code is syntactically correct but se- draws forth the crucial knowledge, and in a mo- mantically wrong, or where there’s a fault in the ment of epiphany, the answer becomes obvious design itself. Such slips can easily cause hours of This first mechanism would therefore lead us problems at a later date. The ability to catch mis- to predict that programmers who chat about their takes early in an online code review is only one programs more should be more productive and benefit of two pairs of eyes: perhaps even more im- that those who pose occasional deep questions for portant is looking at old code with a fresh eye and52 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re
  • a different set of expectations, reading what it re- of learning explored by behavioral psychologists,ally says, not what it ought to say. called operant conditioning, involves learning to This second mechanism also partially explains perform some action spontaneously. This is thethe phenomenon of pair fatigue, which I’ve noticed way that animals learn to perform tricks in circusin myself and others. When two programmers pair acts or domestic dogs are taught obedience. Antogether, the things they notice and fail to notice animal has a variety of behaviors that it engagesbecome more similar. Eventually, the benefit from in occasionally, and with operant conditioning, wetwo pairs of eyes becomes negligible. Beck sug- can supply the animal with a reward after we ob-gested that pairs should rotate at frequent intervals, serve it doing what we want (which reinforces theperhaps once or twice a day.1 Arlo Belshee found behavior). As this reinforcement process continues,that in a jelled team, rotating after two hours was the desired behavior becomes more likely to hap-optimal.18 Some pair programmers regard rota- pen spontaneously, even when no reward is given.tion as an optional part of the practice, and on a Of course, if the rewards stop entirely, the be-small team, or with few programmers willing to havior diminishes and finally ceases, a processpair, there might be little alternative. However, known as extinction (which happens quite slowly).pair fatigue means they’ll ultimately be much less If we supply a further reinforcement before the be-productive. havior has entirely ceased, we can easily restore it On the other hand, because a great deal of ex- to full strength. In fact, learning happens quickestpert knowledge is probably in the form of catego- if the reward pattern is unpredictable, with a so-ries in long-term memory, a novice might be un- called variable ratio (VR) schedule of reinforce-able to distinguish between events experienced at ment. Henry Gleitman and his colleagues explain:different times. Experts really can see things thatnovices can’t. We could therefore predict that this In a VR schedule, there is no way for the ani-second mechanism will bring the maximum ben- mal to know which of its responses will bringefit to novice pairs; indeed, the most extensive ex- the next reward. Perhaps one response willperiment with novice pairs and experts found that do the trick, or perhaps it will take a hundrednovice pairs benefited the most.19 more. This uncertainty helps explain why VR schedules produce such high levels ofMechanism 3: responding in humans and other creatures.Fighting Poor Practices Although this is easily demonstrated inAs programmers, we don’t always use the best the laboratory, more persuasive evidencepractices. An advantage of pair programming is comes from any gambling casino. There, slotsaid to be pair pressure, the feeling of not wanting machines pay off on a VR schedule, with theto let your partner down.20 But why is this nec- ‘reinforcement schedule’ adjusted so that theessary? Why do we persist in poor programming ‘responses’ occur at a very high rate, ensuringpractices when we know they’re poor? Is there that the casino will be lucrative for its ownerssomething special about programming that makes and not for its patrons.21it more difficult to do the right thing? It appearsthat there is. This learning is unconscious: we need not realize Let’s look at a particular example of worst that it’s happening to us, and in the case of the ca-practice: the code-and-fix style of programming sino, a machine instead of a real person is condi-most often used by novices (and sadly, often used tioning the slot-machine patrons. In our habitualby more experienced programmers). Programmers patterns of software development, we too can bewrite some code that they hope will do a particu- conditioned by our machines. This is the speciallar thing and then run it to see what happens. If property of interactive programming that makesit appears to work, they press on with other code, it difficult to do the right thing. With code andwithout systematically searching for flaws. When fix, we tinker haphazardly with our programs, ef-it fails, which is often the case, they tinker with the fectively putting a coin into the slot machine eachcode haphazardly until it appears to work. Why time we run our code. Slot machines are knownis this style of programming so compelling and so as the most addictive form of gambling, and theeasy to discover independently? similarly unpredictable rewards from code-and- Traditional behavioral psychology offers a very fix programming mean that it could be equallyplausible explanation, although more modern addictive.work on the neuroscience of learning and addic- How can we resist this addiction? Perhapstion also points in the same direction. One form we can try to “just say no” and choose a differ- January/February 2010 I E E E S O F T W A R E  53
  • ent development pattern. Some development pro- tell just by meeting them. “I can’t tell, even now,” he cesses attempt to remove temptation by being less wrote. “You also can’t tell from their résumés.”25 Some interactive. Edsger Dijkstra suggested that stu- This is my experience, too: it isn’t enough to programmers dents shouldn’t be allowed near a computer un- til they’d learned to write programs away from talk with someone about programming; you have to work on a problem with them to gauge their ex- are up to one.22 Such ideas might have once had merit, but pertise. A weak version of this technique is stan- 10 times more it seems foolish to turn our backs on the orders-of- magnitude increase in computer power available dard practice in programming interviews. After the preliminary discussion centered on the appli- productive to us. cant’s résumé, the interview proceeds to a series of than others. Pair programmers might be less susceptible to successively more difficult programming exercises poor practices because they can promise to write that the applicant has to talk through at a white- code in a particular way and ensure that each board. I’m frequently surprised by how a very other’s promises are kept. The prevalence of two- plausible-sounding candidate, when challenged people working in jobs where human fallibility is in this way, completely fails to produce even the a serious problem should lead us to seriously con- most basic evidence of the knowledge that he or sider that pair pressure might be the solution for she earlier claimed. us, too. However, you can only keep a promise if Sadly, these poor candidates seem blissfully you made one in the first place. We should there- unaware of their own lack of expertise. They’re fore expect that to benefit from the third mecha- so bad that they don’t realize how bad they are, nism, programmers must agree in advance how probably because, in the words of Justin Kruger they’re going to write and test their code. and David Dunning, “the same knowledge that underlies the ability to produce correct judgments Mechanism 4: Sharing is also the knowledge that underlies the ability to and Judging Expertise recognize correct judgment.”26 In a field where Even within a single development team, conven- expertise is hard to measure, this is a serious prob- tional wisdom says that some programmers are lem, because as Kruger and Dunning observed, up to 10 times more productive than others.23 the less competent are often more confident of Certainly we see a wide range of expertise, but their own ability than their more expert peers. how confident can we be in saying who contrib- The most competent, on the other hand, suffer utes most to overall productivity? Assigning credit from the opposite problem, the false consensus ef- for success is difficult in team activities because fect, in which they believe that their own abilities there are so many variables. are typical. This happens for the same reason: it’s In some fields, it’s easy to recognize experts hard to accurately assess others’ competence, so because individual contributions are simple to the most competent have no reason to believe that measure. Chess players have numerical rankings; they’re extraordinary—unless they work closely golfers have handicaps. These are good predic- with another programmer on the same problem. tors of their likely success against other players. Most programmers work on problems on their But in team activities, so many factors contribute own, so no one knows how good (or bad) they re- to success or failure that we simply can’t under- ally are. But with pair programming, people con- stand the causal relationships without a detailed tinually work together. Because they keep swapping scientific investigation, so we usually select one or pairs, everyone on the team learns who’s the most two arbitrary factors to simplify the analysis.24 In expert at particular things. From this comparison, software development, “lines of code written per they also realize their own level of expertise. We day” often gets elevated above all others, simply should therefore expect more accurate estimates because it’s easy to measure. But selecting such of time and difficulty by a pair programming team arbitrary factors tends to promote “star players” than from a solo programming team. From my ex- who demonstrate those qualities but don’t signifi- perience, this does appear to be the case. cantly contribute to the team’s success. W Unfortunately, more detailed scientific analysis is seldom practical. So how can we assign individ- e’re no longer in the first flush of ual credit (or blame) for team performance? Paul pair programming, yet the gulf be- Graham said that when an expert programmer tween enthusiasts and critics seems works alongside another programmer on the same as wide as ever. Experimental evidence has been problem, the expert can judge the other program- equivocal. How can we advance our understand- mer’s skill. But that’s the only way: he or she can’t ing? I believe the mechanisms I describe here are54 IEEE SOFT WARE w w w. c o m p u t e r. o rg /s o f t w a re
  • among the fundamental properties shared by all About the Authorinstances of successful pair programming, but Stuart Wray is a senior lecturer at the Royal School of Signals. His research interestsother mechanisms are important, too: for ex- include the psychology of programming, computer security, and functional programming.ample, team jelling appears to have a significant Wray has a PhD in computer science from the University of Cambridge. Since then, he’seffect. What other mechanisms are significant? worked in research at the Olivetti Research Laboratory and the University of Cambridge Computer Laboratory, and in product development at Virata, Marconi, and BAE Systems.Although I believe that pairing works the same Contact him at swray@bournemouth.ac.uk.in agile and non-agile settings, this has yet tobe established. In addition, there might be anti-mechanisms: poor practices that lead to unsuc-cessful pair programming and that aren’t merely Programming Interest Group (PPIG 07), Psychology of Programming Interest Group, 2005, pp. 215–226;the absence of the beneficial mechanisms. To in- www.ppig.org/papers/17th-sturdy.pdf.vestigate all of these, we could solicit suggestions 10. M. Chi et al., “Eliciting Self-Explanations Improvesfrom working developers; ethnographic research- Understanding” Cognitive Science, vol. 18, no. 3, 1994, pp. 439–477.ers could reexamine their records for evidence for 11. R. Roscoe and M. Chi, “The Influence of the Tutee inor against the mechanisms. Learning by Peer Tutoring,” Presented at 26th Ann. We also need some form of objective check- Conf. Cognitive Science Soc., 2004; www.cogsci. northwestern.edu/cogsci2004/papers/paper278.pdf.list to compare results across experiments, so that 12. L. Hermer-Vazquez, E.S. Spelke, and A.S. Katsnelson,experimenters can agree how much a particular “Sources of Flexibility in Human Cognition: Dual-Task Studies of Space and Language,” Cognitive Psychology,programming team uses a particular mechanism. vol. 39, no. 1, 1999, pp. 3–36.With such a checklist, we could then reexamine 13. A. Newton and J. de Villiers, “Thinking While Talking:the experiments that Dybå described7 and attempt Adults Fail False-Belief Reasoning,” Psychological Sci- ence, vol. 18, no. 7, 2007, pp. 574–579.to establish the extent to which the teams used cer- 14. P. Carruthers, “The Cognitive Functions of Language,”tain mechanisms. However, such post hoc analysis Behavioral and Brain Sciences, vol. 25, no. 6, 2002, pp.could still give equivocal results. To clearly estab- 657–726. 15. D. Simons and D. Levin, “Failure to Detect Changes tolish the mechanisms’ impact, we must design new People During Real-World Interaction,” Psychonomicexperiments that properly control for them. Bull. and Rev., vol. 5, no. 4, 1998, pp. 644–649. Perhaps you have some other questions—or 16. N. Charness et al., The Cambridge Handbook of Expertise and Expert Performance, Cambridge Univ.even some answers—in mind right now. If so, Press, 2006.I invite you to share your comments on the Web 17. D.J. Simons and C.F. Chabris, “Gorillas in Our Midst:site (http://computingnow.computer.org/wray). In Sustained Inattentional Blindness for Dynamic Events,” Perception, vol. 28, no. 9, 1999, pp. 1059–1074.any case, I hope that thinking about these mecha- 18. A. Belshee, “Promiscuous Pairing and Beginner’s Mind:nisms will help you apply pair programming more Embrace Inexperience,” Proc. Agile Development Conf.effectively. (AGILE 05), IEEE CS Press, 2005, pp. 125–131. 19. E. Arishholm et al., “Evaluating Pair Programming with Respect to System Complexity and ProgrammerReferences Expertise,” IEEE Trans. Software Eng., vol. 33, no. 2, 1. K. Beck, Extreme Programming Explained: Embrace 2007, pp. 65–86. Change, 1st ed., Addison-Wesley, 2000. 20. L. Williams and R. Kessler, “The Effects of ‘Pair- 2. L. Williams and R. Kessler, Pair Programming Illumi- Pressure’ and ‘Pair-Learning’ on Software Engineering nated, Addison-Wesley, 2003. Education,” Proc. 13th Ann. Conf. Software Eng. 3. J. Chong and T. Hurlbutt, “The Social Dynamics of Education and Training (CSEE&T 00), IEEE CS Press, Pair Programming,” Proc. 29th Int’l Conf. Software 2000, pp. 59–65. Eng. (ICSE 07), IEEE CS Press, 2007, pp. 354–363. 21. H. Gleitman, A.J. Fridlund, and D. Reisberg, Psychol- 4. S. Bryant, P. Romero, and B. du Boulay, “Pair Program- ogy, 6th ed., W.W. Norton & Co., 2004. ming and the Mysterious Role of the Navigator,” Int’l 2 2. E. Dijkstra, “On the Cruelty of Really Reaching Com- J. Human-Computer Studies, vol. 66, no. 7, 2008, pp. puting Science,” 1988; www.cs.utexas.edu/users/EWD/ 519–529. ewd10xx/EWD1036.PDF. 5. S. Salinger, L. Plonka, and L. Prechelt, “A Coding 23. R. Glass, Facts and Fallacies of Software Engineering, Scheme Development Methodology Using Grounded Addison-Wesley, 2003. Theory for Qualitative Analysis of Pair Programming,” 24. M. Gladwell, “Game Theory,” The New Yorker, Proc. 19th Ann. Workshop Psychology of Program- 29 May 2006; www.newyorker.com/archive/2006/ ming Interest Group (PPIG 07), Psychology of Pro- 05/29/060529crbo_books1. gramming Interest Group, 2007, pp. 144–157; www. 25. P. Graham, “Great Hackers,” 2004; www.paulgraham. ppig.org/papers/19th-Salinger.pdf. com/gh.html. 6. M. Stephens and D. Rosenberg, Extreme Programming 26. J. Kruger and D. Dunning, “Unskilled and Unaware Refactored: The Case against XP, Apress, 2003. of It: How Difficulties in Recognizing One’s Own 7. T. Dybå et al., “Are Two Heads Better than One? On Incompetence Lead to Inflated Self-Assessments,” J. the Effectiveness of Pair Programming,” IEEE Soft- Personality and Social Psychology, vol. 77, no. 6, 1999, ware, vol. 24, no. 6, 2007, pp. 12–15. pp. 1121–1134. 8. B. Kernighan and R. Pike, The Practice of Program- ming, Addison-Wesley, 1999. 9. J. Sturdy, “Sidebrain: A Sidekick for the Programmer’s Selected CS articles and columns are also available Brain,” Proc. 17th Ann. Workshop Psychology of for free at http://ComputingNow.computer.org January/February 2010 I E E E S O F T W A R E  55