Pair Programming Limitations

Part of the discussion on PairProgramming.

What kinds of tasks are best performed alone?

I have a little experience with pair programming and have become fully convinced of its value. But are there times when an individual needs to tackle a programming related problem alone? For example:

I was trying to solve a programming design problem where every way I approached the problem it read every one of N records on the order of N-squared times. These solutions were of no use. Knowing what I do now, I would have tested them, implemented them, and started refactoring with one of my peers. At the time, I got one of my peers in front of a big blackboard and we invented a half dozen algorithms in three sessions over two days and proved that they were all N-squared. Two days later, with my feet propped up at my desk, I pushed through to an order-N algorithm and coded it up in an hour. Knowing what I know now, I would have penciled the pseudo-code while I had it in my head, then found someone to pair with in order to turn it into a program.

If I had started off coding an order-N-squared version, would I have ever found the order-N algorithm? Would I have found something better? I submit that I would never have found the particular type of required backward thinking with someone else in the room. Of course we'll never know, but I was the man on the spot so my opinion is worth more than yours. Nor would I have found it without working through all the wrong options with another programmer.

Hypothesis: If pairing off doesn't work, try working on it alone.

Signed: GeorgeSxCowan

Pair programming, and other kinds of cooperative work, have an unavoidable cost: talking. Partners have to discuss everything, even trivial and non-controversial topics. Conversations can also wander away and distract people. It might be productive to write easy things alone, then show one's work to the partner and guide discussion to the few interesting points. The above anecdote shows that people can better concentrate and solve problems when they are alone.

- Lorenzo Gatti

That's utter hogwash. Creative impulses can come at any time, with or without a partner. Consider Crick and Watson deriving the structure of DNA -- using your logic I could say that people can better solve problems and concentrate when they're with one other person... -KyleBrown

Most programming problems are shallow, not deep, but there are some that are the other way around. If you wanted to add a search-and-replace function to your text-editor, it would be more helpful to have a partner, because e would catch all kinds of exceptions you might not. But in the rare case where you have to do something really brainy -- come up with a dramatically different algorithm for analyzing music, or visualizing traffic patterns, or optimizing object rendering in your first-person-shooter -- maybe it would be better to lock yourself in a room for a day or two and scribble out formulas.

Or maybe not. Perhaps one of the implicit principles behind PairProgramming, and ExtremeProgramming in general, is that there are very few problems that actually need to be approached by this. And figuring out which problems do need this approach seems a bit too mysterious. It's just as easy to imagine a situation where you tell the other programmers "Nobody talk to me this week; I need to work out a way to do X with an order of N*log(N)" and someone else says "Well why don't you just use Y algorithm? I used it last year; if we grab a computer I can show you how it works."

You don't know how far away a solution is until you're actually there.

It's impractical to expect 100% pairing. Often there are odd numbers of people.

If you're doing ExtremeProgramming, remember that the rule is all *production* code should be built by a pair. R&D, spikes, whatever you want to call them, can certainly be done off by yourself. However, one of the goals of pairing is to ensure that some schmuck in a cube doesn't introduce CrapCode? or otherwise further degrade the system. So, go off and do your mulling, come back with a solution, and we--i.e. you and me as a pair--will build it the right way (probably using TDD). --JeffLangr

If someone is going to introduce CrapCode? if not watched like a hawk by a pair partner, does he really belong on your team in the first place? I'd rather work with colleagues who don't need a pair to build it the right way (see my further comments below). I love pairing for certain things. I just don't think 100% is necessary. --MarnenLaibowKoser, 8 Oct 2011

If someone is going to wash out of a team, the biggest symptom might be rough pairing. Don't blame the pairing! --PhlIp

One of the cases where I've found PairProgramming to not work so well is when you need to read something other than code. For example, you might be reading the "getting started" guide for a library you've never used, or you're browsing forums for solutions to a problem that you're having. You might pick up a hardcopy book to figure something out. All of these cases seem to look like some sort of "research."

What I find to work well is to have my laptop near our pair station. When research needs to be done, one person uses the desktop, and the other uses the laptop.

Perhaps at this point we're already outside the realm of Pair Programming. --DanYankowsky?

I love PairProgramming in some circumstances -- it's a great way to get a new person up to speed on a project, or to tackle a difficult problem, and with certain pair partners, there's a symbiotic flow of ideas that leads to exhilarating design, amazing code, and a satisfaction that's better than sex (OK, not quite :) ). But unfortunately, I'm also a bit of a territorial loner at times. I like having my own space and dev environment set up just the way I want it, and there are times when I really don't want anyone looking over my shoulder as I code: I can sometimes code better if I don't have the overhead of social interaction, and I take enough pride in my work that I don't really need a pair partner to prevent me from producing bad code (or so I believe...).

I guess what I'm getting at is that I'm not sure that the XP dictum that all production code must be created by a pair is such a great idea. I've done amazing things with pair partners, but I've also done amazing things without them, and if I had to work in an environment where I was never allowed to code alone -- or where I had to (IMHO wastefully) throw away any code I wrote alone and rewrite it with a partner -- I think I'd quickly burn out. I need some time at work to focus only on the code without social interaction, I think. (Maybe that means I'm just not suited for BookXp -- a shame, since I agree with most of the Extreme ideals.)

Hmmm. I'm a composer as well as a programmer, and I approach my programming with a certain artistic attitude as well (which I like to think improves my code). I can't in my wildest dreams imagine pair composing (actually, I did it for one brief session -- it didn't go that well), and I doubt that anyone would seriously suggest trying such a thing. So why should programming be different?

No answers, just questions. I hope this spurs further thought and discussion. --MarnenLaibowKoser, 8 Oct 2011

I love PairProgramming. However, deep research is difficult while pair programming. --AndyPliszka