Pair Programming Objections

I have read most of the extreme programming practices and have this comment. If pair programming is so advantageous, then why not pair everything in software development ? Why not pair project manage, pair design, pair test, pair product strategize, pair staff manage and pair CEO ? Wouldn't all the inherit benefits of pair programming exist in all other positions as well ?

Good ideas. They might work. And your objections?

Not exactly objections, but only some activities are suitable for multiple heads working them - usually creative and accuracy problems, which mean design, test, strategize would be candidates, while project management, staff management, and CEO stuff would not be. Staff management by pairs has been shown to be dodgy at best (MatrixManagement, anyone?), and the other two are prone to similar problems. --PeteHardie

I did PairProjectManagement? once: Tricky; not everyone can do it. In fact, we split responsibilities -- I was technical lead, and he did administration. The two people have to have a lot of respect for each other, and you have to be careful of others who would play you off of each other. (In many ways, this experience was very unlike PairProgramming: We didn't do things together; we split the responsibilities.) -- JeffGrigg

(Maybe it should be made clear that PairSomething? implies that the responsibilities are equally shared, not split. At least that is what PairProgramming implies, and it seems to me that if we are going to discuss PairSomething? by analogy to PairProgramming, this crucial aspect of the latter should be preserved in the analogy.)

The idea behind PairProgramming is that: if code walkthroughs are good then let's do them all the time -- i.e. PairProgramming. Remember why this is needed: programming is inherently easy to mess up, even typos can be the source of expensive bugs.

I see very little advantage in PairManagement? -- just think -- every 2 managers will need a third manager above them ... imagine the infinite recursion ..:-) NissimHadar

Another infininte series: if pairs of programmers are good, then surely pairs of pairs will be even better! --DaveWhipp

If you look around, even in your group where "pairing" is not overtly embraced, you may find that the unexpected and more critical problems are actually being handled by two or more people. I see this often in situations where a database has to be patched, for example. But when I suggest people write code in pairs, the same people have long lists of objections.

However in PairProgramming, both people are working right there, right then, and can reach agreement if they have differences in opinion; while PairManaging is unlikely to be done that way - each manager will visit one his/her own, forcing the managed to resolve any conflicts in goals. --PeteHardie

Pair managers must be surgically joined at the hip; then and only then will pair management work properly.

I'm willing to accept that as a necessary precondition to PairManaging.

I worked for pair managers once. When it works it is great. The managers had a solid relationship, they had moved up in the company from the same place and they worked very well together. Their manager always had some idea of what they were responsible for, and some idea of who worked for each of them, but on the ground I never knew whether I worked for one guy or the other. We just all worked together and did what needed doing. -- MichaelFeathers

CategoryPairProgramming