When my boss first proposed XP in 2001, I was horrified. One reason was that I just knew that pair programming was a bad idea. I was certain of it. The first few times, I had stage fright. It was hard. Things did not go well. My first pair, to this day, does not let me forget the body-slamming. It took me about 6 months to warm up to pairing, partly because it was hard to get over bad habits. If this sounds like a traumatic experience, that’s because it was. Now I realize that pair programming demands more skill than I had initially reckoned, and depends a lot on who I’m pairing with, and what we’re working on. Pair programming didn’t turn out to be what I thought it was going to be, and when I finally went back to solo programming 3 years later, it was an eye-opener. It’s like the old saying, “the purpose of a journey is to come back to the place where you started, and know it for the first time.”
If you just throw 2 programmers together, there’s no telling whether they’ll pick up the right skills, or spin apart because of personality issues. Also, it’s hardly worthwhile with cubicle furniture where you have to sit in a corner like a bad child – you end up looking over the other programmer’s shoulder. I hate that. I won’t do it. Either ditch the cheap cubicle furniture, or don’t bother trying to pair program. Side by side collaboration is great. Looking over shoulders is not.
If the two programmers are at different levels, it’s automatically a teacher-student relationship. Most programmers are familiar with being a student, but few have any teaching skills. That’s a real problem. Teaching skills are a subset of pair programming skills, and they’re important.
These days, I usually prefer pair programming, but I look at it in a fairly agnostic way. It’s like when a friend called me a “Mac zealot” because I bought a Mac, and I replied, “No, that’s not the issue. The issue is that I know 3 operating systems, and you only know 2.” Same thing: I can pair program, and I can solo program. Can you? There are many programmers that can only solo program, and aren’t even aware that they’re missing something, and will even denigrate me for knowing something that they don’t. (Of course, they spin it a different way.)
I’ve been a professional programmer for over 15 years now, and my experiences with code reviews have been mixed, but I have yet to see a code review produce quality anywhere near as good as pair programming. It’s just not in the same league. But maybe we just never did it right. I hope so. YMMV, as many have wisely observed already. Recently I met a programmer with 24 years of experience, who had never worked on a team, and that shocked me because my experience has been nearly the opposite. Most of my career has been on teams.
I’m currently on my 4th pair-programming team, and once again, I’ve learned something new. I previously thought that pairing made even-numbered teams preferable. But with 7 people, I find that having an odd man out keeps the pair swapping fluid. With an even number of pairs, there is always a problem with pairs locking up, not enough people wanting to rotate. Live and learn. “A man with a watch always knows what time it is. But a man with two watches is never quite sure.” Probably after my next pairing team, I’ll have an even more nuanced view of things.
As for productivity: I think that pairing is somewhat less productive in the short term, but more productive in the long term (on the scale of ~10 months, roughly, YMMV, standard disclaimers apply). This is because of the knowledge sharing when pairing; solo programming teams simply bog down sooner.
