Craig Castelaz's Blog

Pair programming: Everyone's favorite argument

I don’t know how it is for you, but nearly every conversation I’ve ever had about extreme programming eventually works its way to pair programming, which pretty much kills the dialog part of the conversation. Pair programming is apparently best discussed in monologue format. For most of the developers I’ve listened to, it is “The” extreme in extreme programming. It is either the single greatest advance in Western Civilization since the windowed envelop, or it is the spawn of the Netherworld.

Briefly, Pair Programming is what it sounds like, two programmers working together on the same computer. One is the pilot who does the actual coding. The other is the navigator who serves as both guide and companion. The programmers collaborate during the development session. They occasionally switch roles, so no one gets to monopolize the process. Its advocates claim pair programming results in higher quality code and increased programmer confidence. In addition, some experts believe these gains can be achieved with little or loss in productivity, while others go further, and hold that the pairs are substantially more productive than a single programmer working alone.

There have been a number of studies examining these claims. The current issue of IEEE Software has the latest, “A Field Study of Developer Pairs: Productivity Impacts and Implications”. The article is a reexamination of data collective during a previous study conducted by the authors. In the prior study, the researchers found that “…teams are more productive when their members work independently.” These findings where published just as agile development techniques with their promises of higher quality and increased productivity were gaining attention and serious study. Several subsequently published papers substantiated pair programming’s claims, hence the desire to reexamine the data.

In the new study, the authors have to resort to a notion of concurrency. Since the data was originally collected prior to general knowledge of pair programming, it does not record when programmers actually worked together as a pair. However, the researchers could determine when developers worked on the same module on the same day. They called this concurrency, “collaboration potential”. Although the authors recognize the measure doesn’t directly reflect pair programming, they argue concurrency is “…a necessary precursor, positively correlated with collaboration….” In other words, it’s the closest measure of pair programming the data will yield.

As to the findings, the researchers report that low-concurrency pairs (those working most independently of one another) were four times more productive than the potentially more collaborative high-concurrency pairs. That is, the reexamination of the existing data does not substantiate the productivity claims of the other studies. The authors then go onto propose that the difference might lie with the pair programming protocol itself, i.e. the pilot/navigator roles, and the switching between them that occurs during the development session.

Perhaps there is something within the pair programming protocol that would account for the productivity gains reported in the other studies mentioned by the authors. Then again, the difference may lie within the environments examined by the different researchers. One of the earlier studies looked into the productivity of experienced developers who participated in a short 45-minute pair programming exercise, while the other concerned itself with undergraduate Computer Science students who were paired during a semester. This latest study, however, was based upon data collected during a port of a legacy system which involved 3000 screens and a million lines of code. Without criticizing the earlier studies, you can still ask how well they translate to the “real world”.

So, the controversy remains unresolved. There are indeed studies that back up the claims of pair programming’s proponents, especially in terms of higher code quality and programmer satisfaction/confidence. However, the jury is still out on the cost in productivity. It looks like conversations about extreme programming will continue to devolve into monologues.

Comments

• Quality and Productivity are not mutually exclusive
  To say that pair programming improves code quality at the expense of productivity is misleading. Improved code quality *increases* productivity, by virtue of the fact that you spend less time doing maintenance and bugfixing.

  As we all know, these tasks can take up a huge amount of our time, and anything which can reduce that will improve overall productivity. My personal experience of pairing (as a former XP-sceptic) has shown that the substantial quality improvements more than offsets the slightly longer time taken to write the code in a pair.

  Furthermore, when you're working on your own, there's a tendency to run off on wild goose chases. When part of a pair, this is far less likely - the other person will be there to pull you back to reality. This would be an example of a direct improvement to productivity when pairing.

  Posted by: skaffman on September 17, 2004 at 06:31 AM

• Seemed to be of benefit when I did it.
  Although quick disclaimer I did it in college not the real world. Although I coded 40 hours a week for school, compared to about 20 hours a week in the real world.
  What I found was that I didn’t code any slower because someone was watching me, but I did code better.

  You end up reciting every line of code you put down aiding long term memory in remembering what you did then next morning.
  The Church of Latter day Saints, already knows that pair of people deviate less from norms. The same is true in development with unit testing, programming to interfaces, and resisting shortcuts.
  I always find that my biggest hindrance in development is holding context in my head, remembering interactions, and knowing exactly the responsibilities of each object. What I’m going to code next sometimes gets lost and I just have to stop and recomprehend it all. In pair programming you always have twice the short-term memory to hold you context.
  You catch bugs that would take you time to fix later. Not only does having somebody watch allow them to catch bugs as you type, but it makes you more aware of what you’re doing and you catch more of your own mistakes.
  How many times have you wanted to bounce a quick reality check off of another developer, well he’s sitting next to you.
  

  Posted by: matt_meyer on September 17, 2004 at 06:51 AM

• higher productivity
  When paired, you're bound to be more productive because you'll both be working on the code that's in front of you, with no chance to shirk by reading email, surfing, or, erm, posting comments to java.net :)

  Posted by: lee_ on September 17, 2004 at 07:09 AM

• Constant code review
  An argument for PP is that there is a constant code review as the pair discuss the code as they write it. And yet, I've seen in practice that two can be as stupid as one. I have reviewed code written by pairs and thought things like how did they both miss that?

  So you can't pair junior with junior because they'll still write poor code. You don't want to waste expensive resource pairing two seniors. And some seniors feel resentful of being lumbered with a junior, slowing them down.

  A previous project manager thought that engineers are somehow plug-compatible. The less good programmers would learn at the side of the masters and will become better programmers. The masters think they'd be better off just getting on with their jobs alone.

  Posted by: arae on September 17, 2004 at 07:11 AM

• It depends on the pair
  I would love to find someone who I could pair program with, but that's because I am a Meyers-Briggs ENFP personality type. I enjoy collaborating with others. That's not true of everybody, and its not a necessary personality trait to be a good software developer.

  For any of these studies to be truly helpful to a manager, the researchers would have to take into consideration the personality types of the participants.

  You have to adapt your development process to what works best for the people that you have. Trying to change people's personalities seldom works.

  Posted by: johnreynolds on September 17, 2004 at 08:10 AM

• P.S. Great illustration!
  

  Posted by: johnreynolds on September 17, 2004 at 08:11 AM

• Study sounds irrelevant
  Well, I didn't read the actual study, but from your description it sounds like their data and analysis are completely irrelevant. I "collaborate" a lot with the guy sitting next to me, but I wish we were pair programming. Then we wouldn't have to go through the painful source control cycle which wastes lots of time every time we "collaborate". We wouldn't be doing things different ways and would be finding lots more opportunities to share code. His code would have JUnit tests. And I would probably feel better that my tests were adequate (and so spend less time wondering, "Have I written enough tests? Is this a good test? Can I move on?").

  The source control issue is one that I don't see mentioned much, but I think if you took 10 developers and paired them so you only had 5 teams doing check-ins, you'd get a big boost right there in overhead reduction.

  Posted by: detorres on September 17, 2004 at 08:56 AM

• Study sounds irrelevant
  One of the difficulties mentioned by nearly every study was the problem of collectting the data noninvasively. Clearly, reexamining exiting data is pretty noninvasive, but as you point out the results may be irrelevant. I particularly lilked your comments about unit testing. I hadn't thought of the possibility of using pairs to decide how much is enough.

  Posted by: castelaz on September 17, 2004 at 09:18 AM

• Study sounds irrelevant
  I agree with detorres, it does not sound like they have any data that can back any conclusions about pair programming.

  They do not know when people have programmed in pairs.

  They know when two persons have worked on the same module on the same day.

  If the two persons were not working as a pair, they would have to waste time on communicating or merging changes.

  If the two persons were working as a pair, there is a chance that their code would have been commited under a single user name - hence real programming pairs do not show up in the data.

  So what the study shows is that: "You are less productive if you work on a module that is concurrently modified by someone else".
  

  Posted by: giddy on September 17, 2004 at 09:29 AM

• It depends on the pair
  I'm not sure of my personality type, or if I even have one, but I've encountered the same reluctance to collaborate. Perhaps its the potential criticism of one's work that keeps many from even trying pair programming. What could be a valuable learning experience for both participants might feel like an endless rag on your code. I'm not sure that the advocates of pair programming give enough credit to the difficulties inherent in collaboration. As you point out, its not everyone's cup of tea, nor does everyone have the interpersonal skills to negotiate the shoals of collaboration.

  Posted by: castelaz on September 17, 2004 at 09:29 AM

• P.S. Great illustration!
  Thanks.

  Posted by: castelaz on September 17, 2004 at 09:31 AM

• Seemed to be of benefit when I did it.
  Your experiences in college appear to match many of the undergraduates in the study, “Building Pair Programming Knowledge through a Family of Experiments”. Most reported that the experience was worthwhile. Pair programming appears to be very beneficial in a learning environment. Your last point really rang a bell with me. Many years ago, when my oldest child was still a baby, I stayed home with her during the day, and contract programmed at night. There were very few nights that I didn't wish I had another programmer to go to for a quick reality check.

  Posted by: castelaz on September 17, 2004 at 09:41 AM

• higher productivity
  Now, who would do that? :)

  Posted by: castelaz on September 17, 2004 at 09:42 AM

• What happened to no silver bullets?
  The biggest problem I have with XP is that it is often treated as a silver bullet by its proponents. How many times do we have to go back to "one size fits all actually fits no one". The assumption is often that every project is well suited to XP and every team should be an XP team. None of this is true. The other problem is that XP is often an "all or nothing" approach, which is why I think we've seen the development of Agile methodology as a gentler pill to swallow.

  The second problem I've often experienced with XP is that its biggest proponents are often its worst practicioners. While they may talk about all of the benefits, they're usually the keyboard hogs and the ones likely to go it alone because of habit. My other experience has been that when one developer thinks any deviation from their way is "wrong" then pair programming is very unpleasant.

  On a personal level, I find coding to be an enjoyable intellectual exercise. I find watching someone code about as stimulating as watching paint dry. XP, despite the "extreme" in its title alluring to excitement and danger, is about the most boring programming methodology I've ever been a part of. It actually makes my job less fun. I'd like to think wanting to enjoy my work is not a bad thing.

  Lastly, I agree with Kathy Sierra's comments she made some time back in her weblog.

  http://weblogs.java.net/pub/wlg/1159

  What do we do with people who are technically capable but socially introverted with XP? Do we simply cast them aside as unfit? Again, the "one size fits all" mentality seems to fall short.

  I also think, economically, it's a bad idea. There are no studies that support many of XP's claims and many seem to actually counter what XP claims. For every XP success story there is AT LEAST one failure story. With costs being a major issue and off-shoring looking so alluring because it "looks" cheaper on paper, is it really a good idea to have the appearance of two programmers doing half the work? That may not be what is happening in reality, in fact they may very well be over twice as productive (if you take into account code quality). However, the bean counters don't see this. It looks like a waste of very expensive resources.

  I'm not saying XP should never be used or even that it is a bad methodology. I do think that its greatest myth though is that it is THE way to go for everything. To be honest, the businesses I've seen enjoy the greatest success often develop their own technology culture, which often can develop its own methodology over time. If carefully nutured it can lead to many of the benefits XP claims to have. I'm very leery of "package" methodologies because they are developed within the confines of originators experience and rarely take into account the wide variety of corporate cultures, individual working habits, and actual needs of the organizations.

  Posted by: rob_aught on September 17, 2004 at 09:44 AM

• More productive and fewer errors, but does that mean more value?
  I don't have any problem with the idea that two programmers working together as one on a problem is more productive than one person doing it alone. But does that really relate to the challenges of an average development department?

  You may have a number of unrelated (or loosely related) projects that require attention. Even within a project, the codebase can easily be large enough that people could be working on simultaneous subprojects without directly overlapping.

  So what is the point of comparison? It's easy to say two is better than one. It's fairly easy to say that pairing would be better than two people working individually on overlapping code. But is pair programming on two independent projects sequentially justifiable compared to one developer working on each project simultaneously?

  Assuming you can't afford / justify doubling up on the number of developers, does an effective implementation of pair programming indicate ineffecitve project planning and management?

  Posted by: grahamtriggs on September 18, 2004 at 02:00 AM

• More productive and fewer errors, but does that mean more value?
  Your first question was essentially the same one I asked myself about the study involving programmers pairing up to work together for 45 minutes. I expected the pairs to outperform the single programmers, but what did it have to do with the reality of software development. A sprint isn't a march. As for the cost of pair programming, the argument is that pairs are more productive, consequently you can avoid doubling your development staff. Perhaps. On the other hand, pair programming may indeed be an indication of "ineffective project planning and management".

  Posted by: castelaz on September 18, 2004 at 07:15 PM

• What happened to no silver bullets?
  I sometimes wish there was a big banner in my shop that read, "There are no silver bullets". The banner wouldn't be just me, but for all. In fact, it might be a good idea to hang such a banner where ever programmers ply their trade. You're certainly not alone with many of your criticisms of XP. If you're not familiar with it, you might want to check out "Extreme Programming Refactored: The Case Against XP" by Matt Stephens and Doug Rosenberg. One of their main points in the book is that the initial XP project, the Chrysler "C3" payroll system was not a sucess, which nicely echoes your concerns regarding XP's success rate.

  Posted by: castelaz on September 18, 2004 at 07:31 PM

• Study sounds irrelevant
  Like every study, interpretation is everything. Your conclusion has what the authors might call "inuitive appeal", although I suspect they would never admit it.

  Posted by: castelaz on September 18, 2004 at 07:37 PM

• Constant code review
  The "logistics" of XP is not the trivial matter some of its proponents make it out to be. XP has a reputation of being "people-friendly", yet some of its practices do appear to treat developers as "plug-compatible".

  Posted by: castelaz on September 18, 2004 at 08:04 PM

• Quality and Productivity are not mutually exclusive
  Like much of software development, there are trade-offs. Are you constrained by speed or size? Is it worthwhile making you code reusable? Will you realize the potential savings of quality code? It appears you're make several good trades in the past.
  

  Posted by: castelaz on September 18, 2004 at 08:25 PM

• Pair programming good
  Working in a start-up, i find that pair programming is very effective when working with new or junior people because it allows me to constantly work with the new and younger people even through I am also beign dragged around to meetings all day

  As team lead, I am dragged away from my desk every hour in a very chaotic environment. By pair programming, I can get started on a complex task and show someone how to proceed, then go away for an hour or so, come back, and get right back into the mix.

  Of course, this only works when the programmers are willing. Frequently, programmers seems to have personality defects that prevent them from working together. Additionally, when pair programming, you can immediately recognize the weaker of the pack, and this can be unnerving for many

  Posted by: charlesmartin14 on September 19, 2004 at 01:46 PM

• Junksci...
  Myers-briggs stereotypes aren't exactly the most scientific way of pigeonholing people. Do Scorpios desire pair-programming more than Libras?

  Posted by: philwebster on September 20, 2004 at 01:28 AM

• Bad experience on first XP project
  Before I get onto the issue of pair programming, I think a far more disturbing aspect of XP is the aggressive fear of up front design. Of course the XP advocates will start grumbling about 'waterfall' this and 'locked in' that - but a good design can and should be flexible, bending and flexing in the storm of changing requirements.

  Failure to have a coherent design is what makes me think what is really at the heart of XP is the following premise:

  "that programming is an art"

  When I look at XP it seems that it really only makes sense if you accept that initial premise, and I know that many programmers subscribe to that point of view. And after all, who doesn't want to think that they are an artist? Hanging around in coffee shops, arguing with the beatniks in a sexy French accent, being deep and meaningful, and creating masterpieces that leave the audience astounded, sought after by flocks of admiring fans, etc.*

  *The irony of the contrast between this mental image and the reality of XP practices is left as an exercise for the reader.

  But there is an equally valid point of view, that programming is far more like a science, or engineering.

  It seems to me that XP is an attempt to address the kind of issues you would get if you had to have a bunch of artists working on a project.

  Eg, the big problem with artists is that they goof off all the time, therefore the solution is logical, pair them up to work together so that neither of them has time to goof off. Hence pair programming.

  The current project I'm working on is fairly small, and we have a couple of pair programming advocates.

  What strikes me is that easily 80-90% of their code has been written when they are away from work, at home! This enormous contradiction between what they say to do, and what they actually do is nothing short of breathtaking.

  As the project has gone on the amount of pairing has dropped to virtually nil. What there is, is basically one person standing over the other and fixing the problem (which they introduced into the codebase in the first place by changing some underlying fundamental piece of the code, and sometimes not even bothering to tell the rest of us). At least one of the pair is reduced to the role of a spectator.

  Without conscious effort on my part when I am paired with someone they will often just lapse into silence as they type out the code. I have to keep needling them eg "what are you doing now? why? what do you hope to achieve?".

  When I insisted on driving it was in the hopes that they would then explain where they were headed. But instead what happens is that you end up with the other person practically dictating.

  "s".

  "No, capital S".

  "y, s, t, e, m"

  "dot"

  .... yeah great, thanks guys, I've been programming Java for over 8 years now, I think I know how to spell System.out.println by now!!!!

  In effect if the spectator person can somehow keep interested long enough, they become a glorified spellchecker/compiler.

  "You need a semi-colon on the end of this line"

  "You misspelled GregorianCalendar, it has three 'a's not two"

  "Closing brace here"

  And this is even though we are using Eclipse, a tool which is particularly good at automated nagging.

  Last week for the requirment I was working on I had to interact with Hibernate, (and by proxy, XDoclet), neither of which I'd worked with before this project. The senior XP advocate offered to pair with me, but I decided to have a stab at it myself and see how far I could get before having to call for help. A couple of times when I was reading through the Hibernate FAQ I could see there were two (or more) different ways of doing things, so I'd turn around and ask him which way we were using (and why). I got it done, and in about the same time I figured it would have taken the expert to do (~10% longer). I learned a heck of a lot more than if I'd been the passive spectator in a pair (or even the one taking dictation), and it was immensely much more rewarding than any of the pairing experiences I have had to date.

  Oh, something else strikes me, the concept that people have different learning/communication styles, eg Visual, Auditory or Kinesthetic (learn by seeing, hearing or doing). XP in general with its emphasis on 'spoken documentation' seems to be extremely heavily weighted in favour of Auditory.

  Of course, since I'm heavily Visual, I get frustrated that nothing ever gets written down. That might be part of why some people love it, and others hate it?

  I've done a lot of Rapid Application Development in my time, and it seemed like there the assumption was 'ok, you're a professional, you know what to do, get on with it', but XP isn't like that.

  I'd say to summarise my experience the P stands for 'Pain'.

  Posted by: rickcarson on September 20, 2004 at 05:06 AM

• Pair programming good
  Charles,

  Your comments here don't match up with what I know of XP. You should not be dragged to meetings because in your lab there is to be an "onsite customer". I'm also confused how you can claim to be pair programming constantly even thought you are also dragged around to meetings all day.

  What you described here is not pair programming:
  "get started on a complex task and show someone how to proceed, then go away for an hour or so, come back, and get right back into the mix. "

  Taylor

  Posted by: tcowan on September 20, 2004 at 07:25 AM

• Pair programming good
  As team leader he probably has to have discussions about things not directly project related.

  Should your CEO or CTO be shoved into the project room? Should HR be in there as well? What about your purchasing dept? What about the inevitable discussions with the client reps boss? Should everyone you ever want to get crammed into the closet? No, of course not.

  Consider that in most organizations a project manager may have several projects each with a different team, should they all get crammed into one work space???

  But why would the team leader and project manager ever need to talk?
  

  Posted by: rickcarson on September 20, 2004 at 03:33 PM

• Pair programming good
  You must be mistaking me for a supporter of XP. I think it's ridiculous. It's important that we be fair in a discussion of pair programming. The example that Charles gave isn't pair programming.

  >should they all get crammed into one work >space???

  No, of course not, but I've seen it happen. And actually I think that CTO's that want to use XP should be crammed into labs. If the cross communitcation is beneficial at the developer level, just think of the productivity gains at the CXX level.

  Taylor
  

  Posted by: tcowan on September 21, 2004 at 07:18 AM

This work is licensed under a Creative Commons License.