My hat's off to Obie Fernandez for his recent article 10 Reasons Pair Programming Is Not For the Masses. I don't actually agree that only the elite are cut out for pair programming, but I do think he's on target with his list of obstacles to effective pairing.
There's another axis to consider for fit, however, and that's the suitability of the work itself for pair programming. I don't mean the product domain or the kind of application being written, but rather the technology and tools used to build it.
I started pair programming when I was a freshman in college. My CS10 lab section had 20 students and only 10 computers, so we had to pair up. No one told us anything about how to pair; we just did it. It wasn't really a big deal since students are used to helping each other with class assignments. I think the pairing was valuable for learning, but there was a problem. The problem was Pascal. Specifically, the length of time spent compiling the code every time we made a change. We'd write some code, then fire up the compiler and play Pascal (the game of seeing how many dots you can generate before you get a compiler error). Compiling took a long time, anywhere from 5 to 20 minutes, depending on how big the program was. So what do you do with your pair during that time?
There are all sorts of reasons we hate long wait times during development, whether from compiling, running tests, deployment, or whatever. While it can be nice to take an enforced break now and then, the disruption to flow is a significant obstacle to productivity and quality of work. A five minute interrupt to your flow is murder to your mindset and caustic to your collaborative bond.
After college I worked at Xerox, programming in Smalltalk on a team of about 8 developers. We tended to pair a fair amount, maybe a quarter to half of our time on average. But at other places I worked, we paired a lot less. I'm sure some of that was cultural, but I think a lot of it was because of the technology. Programming in the Smalltalk environment really good for keeping the flow going. Do some coding in a method and save the code, and a second or three later you can see the results. This made pairing so much easier because we could keep our focus on the coding. It's hard enough to keep the pair in a good mode when things are going well, but to have to stop for a few minutes every few minutes adds too much frustration, and the easiest place to direct that frustration is onto your pair.
So if your project is not amenable to a rapid, incremental development cycle, it's going to be a lot harder to keep people pairing on it. I guess that leaves two options. You can punt on pairing, or you can fix the technology so that you get the fast development cycle necessary for maintaining flow. Can you guess which one is going to be better for you?
Doesn't work so well when you're the only developer in an otherwise business-focused team, I can tell you. I still find myself dragging confused colleagues over from time to time to act as sounding board when I'm stuck. Hopefully they learn something while I'm brain-dumping. They seem to tolerate my strangenesses, anyway. On the plus side, when I'm done with an increment, the team's done by definition. If the increment took 5 minutes then so be it - ship.
I haven't done pair programming in the work environment before, so I won't comment on the practice of it. I like silence (no talking around me) when I'm coding/thinking and my own office.
However, I was very turned off by Fernandez's strongly worded article. "Cheap", "under-qualified", "don't work hard"... etc as being reasons for why someone might not be pair programming.
I do wonder if everybody over at HashRocket makes at least $150K else they might be "mediocre and/or anti-social developers".
J: That's because Fernandez's article was only superficially about pair programming; the real purpose behind the article was to tout how awesome his company (and by extension, he) is.
So what do you do while you're waiting for a long compile when you're NOT pairing? It still breaks flow.
As I'm learning to pair, I'm finding that the inevitable pauses to run the spec suite are more productively filled by pairs than when programming solo. In the latter case, I'm likely to start web-surfing. But when I'm pairing, I can have a conversation - possibly about the next thing to do, or about a design decision, or about last night's poker game.
The worst thing is when both of you just sit and stare at the computer. :)