16

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?
Improve this question
6
  • Is this the same thing as "Pair Programming?"
    – Robert Harvey
    Apr 18, 2011 at 18:21
  • @Robert Harvey - Well it is one aspect of pair programming. Once a team decides that they are going to program in pairs (for some proportion of their working day), then they need to decide how to arrange programmers into pairs, i.e. when one programmer should leave a pair (another should join at the same time). That is "Pair Swapping".
    – user23157
    Apr 18, 2011 at 18:32
  • +1 for the great question. Sadly, I think it's hard enough to find a shop that does pairing on a regular basis, let alone enough to have data on pair-swapping. Hopefully i'm wrong about this and you get some good responses, I am very interested in hearing some.
    – Jesse McCulloch
    Apr 18, 2011 at 18:41
  • 2
    I would personally find pair swapping very distracting. Trying to deal with so many different personalities and skill levels in such close quarters would produce too much cognitive dissonance.
    – Robert Harvey
    Apr 18, 2011 at 18:44
  • @Jesse McCulloch - I work at a place that only pair programs and swaps pretty much as the books say a team should. I've also worked in a pure solo environment and so have some fairly good perspective on the contrast. However, I'd like to hear other people's opinions as I'd like to see if they match my own without influencing them too much.
    – user23157
    Apr 18, 2011 at 18:49

3 Answers 3

Reset to default
4

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.

Improve this answer
9
  • Personally, I enjoy pairing with people at all levels. Sometimes I'm learning, sometimes I'm teaching, and sometimes we're just getting things done. But learning and teaching build long-term team capacity, which I think is just as important as checking off features.
    – William Pietri
    Apr 19, 2011 at 5:54
  • you may think so, but the project manager who sees his deadline evaporating as your expertise gets used to train people on his time rather than churning out code as fast as you can wouldn't agree. And that's the way most projects operate, there's simply no time to train people to have the skills needed to do the work so juniors are left dangling, good only for taking the blame for budget overruns.
    – jwenting
    Apr 19, 2011 at 6:10
  • @William Pietri: In my experience pairing is not a good format for teaching. I don't have a problem taking someone and walking them through code to explain to them what's going on. However, that isn't pair programming.
    – snakehiss
    Apr 19, 2011 at 16:10
  • @jwenting: If you're saying pair programming won't work well in shops that focus on bullshit deadlines over quality and sustainability, I wouldn't argue. My tip: work somewhere that isn't insane.
    – William Pietri
    Apr 19, 2011 at 16:13
  • @dietbuddha: Works for me! The fastest way for me to learn a new language, framework, or library is to pair with people who know it well. And I know of no better way to bring a noob up to speed than pairing. E.g., this take on the experience: slesinsky.org/brian/code/starting_xp.html
    – William Pietri
    Apr 19, 2011 at 16:19
3

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.

Improve this answer
2
  • For me I have to say that swapping off is only good when a) I don't enjoy coding with the guy I'm coding with, b) I don't like the story that I'm working on (like fixing a ropey old memory bug). Otherwise I want to stay on from start to finish. Personally I think that pair swapping reduces code quality because good code should have a single clear vision, the more people who work on a single part, the more cluttered that vision becomes. As for sharing knowledge, I'd say that most people get a bit of an idea of what's going on, but no one really properly understands anything.
    – user23157
    Apr 19, 2011 at 19:49
  • @B Tyler - I think a code base is a joint intellectual work, so you have to have a clear vision that is also a common vision. That's part of why I think it's important to swap: it takes a lot of of interaction and discussion to develop a solid shared approach.
    – William Pietri
    Apr 19, 2011 at 21:28
1

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.

Improve this answer
1
  • 1
    Alas I'm now totally converted to the opinion that pair programming is in general a bad idea; frequent pair swapping in pair programming just makes things worse. I've heard all the theory and tried it a lot in practice and I just think that it's incredibly inefficient, much more boring and frustrating than solo programming and results in lower quality code.
    – user23157
    Jul 7, 2011 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.