Pair Swapping: What are the Pros and Cons?

Question

The general idea that is espoused by most Agile / XP theorists seems to be that pairs should swap regularly. For example each programmer should swap pairs once per day; half the people swap at the start of the day, half the people swap after lunch: due to external factors such as meetings, holidays and the like most people will tend to flip their swap times once or twice per week so that the pair configurations distribute fairly evenly across the team.

One rationale behind frequent swapping is that knowledge is spread amongst the team quickly and evenly, rather than having specific skills and knowledge being concentrated in particular individuals - implying that work can continue smoothly if people are either away or leave the company. Another rationale, which is a sort of corollary to the dogma surrounding pair programming itself, is that each time someone swaps on you are getting a new code review by a fresh pair of eyes, so it can only improve code quality.

Both assertions sound reasonable; from a management point of view it sounds like you get an increase in both stability and quality, and as such frequent swapping is pretty much standard theory in most Agile / XP books that I've looked at.

So, when actually put into practice, what do people actually think about pair swapping from

• A programmer's point of view?
• A manager's point of view?

And

• What should determine when someone swaps off of / onto a pair?

Answer 1

Pair Programming is difficult.

It's difficult because it works best when the 2 people involved are close in skill level and that can be difficult in some work environments. It can be more difficult when you swap out because you need to find someone else with the appropriate skill level and then bring them up to speed on the current problem. The benefit is more people have exposure to any given piece of code that has been paired on. This should lead fewer times where code can't get fixed because no one knows enough about it. It should also propagate group ownership and the ability for anyone to pick up any piece of work.

I have found that even in environments where pairing is done, pair swapping is not worth the cost. However, this may be due to our tasks never taking more than ~1.5 days. We found a great benefit to breaking tasks down to be no bigger than ~1.5 days worth of work. Pair swapping may make more sense in the context of longer running tasks.

Answer 2

I'm both a programmer and a manager. Here's my take:

Regular swapping is great. I favor swapping 2-4 times per day, which is about as fast as I think you can go. For us, that comes at natural breaking points: generally lunch and mid-afternoon. Changing every day or two is probably fine, but I'd worry about going a lot longer than that. (I've heard of one place swapping as rarely as every six weeks, which I think is insane; after that much time together you'd be ready to stab a saint.)

As a programmer I love it because I get fresh perspectives, get to check out other areas of the code, and can either stick with or move on from something as I prefer. I just recently went from solo coding back to pairing, and I am thrilled: I learn more, have more fun, and get more done.

As a manager I think it's great because it solves a lot of truck-factor and bottleneck problems. E.g., this weekend I'm taking a long weekend for a friend's wedding, and I am not worried at all: everything I've worked on has also been worked on by other people. I also think it really helps team members to appreciate one another's strengths and weaknesses, and to encourage collective code ownership.

As to who stays with the current work, I feel like it's mainly up to the people involved. Sometimes you want to see something through, and sometimes you're ready for a change. We also sometimes swap to bring in expertise, or so somebody can learn something they're interested in. We try to keep our units of work pretty small (0.5-2.0 pair-days), so it's not a big deal however the swapping goes.

Answer 3

Okie, here goes the answer from a self-proclaimed pragmatic agile/xp programmer. I have been pair programming for more than two years now. If pair programming is good, swapping pairs frequently (ideally every two hours, if not every half-day). In our office location, we make it a point to swap pairs every day(usually) or every two days(in worse case). Doing this in itself could give us a lot of confidence in the quality of code that we commit and learnings or take aways that we have with every pair rotation (we know that code review is good, the more the better and the earlier the nicer. This is what "pair programming, including the practice of swapping pairs" achieves).

Why is that we don't switch pairs every two/four hours? Well, actually I have been in teams that practice this too. It certainly is way way cooler and more productive. But here is the deal, time interval of swapping pairs should not be a rule, it should happen on its own; only then can the manager or the business see its benefits.

I have witnessed and experienced this. I'm now its evangelist. Its no theory. Rather its thoroughly pragmatic :) Happy ping-pong pairing and swapping pairs.