You mentioned that you've "gathered some data which shows that the benefits of pair programming are not enough to offset the loss in productivity." But it strikes me that one advantage of pair programming is that people understand each other's decisions and blindspots better; and many companies spend a lot of time with people reading each other's code, just to see what everyone else has done.

I imagine your teams may be flexible, but since they've been trained for years to operate one way, perhaps some deeper advantages of pair programming can't be captured in your data?

-- Anonymous, April 23, 2001

Answers

Couldn't agree more. Although several tasks aren't faster pairing I have found that pairing is a great team synchronization tool. It gets everyone on the same page and keeps them there as the project progresses. If you have ever worked on a team that "just works" you know what I mean. Once everyone is in step psycologically, emotionally, technically the productivity of the team skyrockets - and people have fun. If you have a team that got there and stays there by other means then perhaps pairing is less valuable?

-- Anonymous, April 24, 2001

Hmm... Joel's studies and opinions, while often useful and interesting, are not very scientific. There has been some academic attention focused around XP and pair programming that might be interesting for anybody thinking seriously about it.

Here's some: http://collaboration.csc.ncsu.edu/laurie/pubs.htm

(base conclusion: people work better in pairs, are happier about it, and produce code that's so good that it's virtually defect free).

Of course, some computer programmers (especially the hard core type) are highly individualistic.

-- Anonymous, April 25, 2001

One possible less publicised advantage of pair programming:

You spend less time surfing the web reading things like JoelonSoftware and more time programming!

-- Anonymous, April 26, 2001

I whole-heartedly agree with the web surfing comment; not that we want to waste time reading the web, it's just that we get caught up in it while doing our four-five minute builds.

I use pair programming as a surgical tool; when a guy on my team is floundering, taking more than a day on a certain feature, I pair him up with someone. This helps to minimize Jim McCarthy's "Guy in a Room" effect: you put your best guy on your hardest task and then twiddle your thumbs while he makes invisible progress.

-- Anonymous, April 26, 2001

As with anything else using pairs, or buddy systems sometimes gives benefits and sometimes gets in the way.

There are times when you do have to send someone off on their own to cogitate, drift and think laterally. That though isn't in the final phase of bug kill, build and test.

-- Anonymous, April 30, 2001

I just think Joel missed the whole point of XP and pair programming. As mentioned earlier, PP is a long studied topic not exclusive to XP. XP has just adopted it because studies, empirical and anecdotal, have shown it works. The benifits of XP and PP aren't really brought out when you are fixing bugs in code. They are brought out when you see that you have less bugs to fix when these practices are used to develop in the first place. The reasoning behind dismissing XP reminds of a kid, who when trying to learn to ride a bike falls off the bike and then gets up saying "This is stupid, it will never work." As we all know, learning to ride a bike takes time. So does implementing a new software development proccess.

--Angus

-- Anonymous, May 04, 2001