Tri Programming

[Extracted from XpMailingList]

Many of us who have tried bi- and tri- programming report that pairing is better. Why?

Here are the reasons I can think of at the moment:

Pairing gives me more typing time. When tri-programming I get bored. I almost never do when pairing, and if I do we both need a break.

Two people fit better in front of a monitor. There's less eye and body strain, leading to better software.

It is easier to manage the body-space requirements of a pair.

Mano-a-mano, pas de deux, Astaire and Rogers, husband and wife, yin and yang. Perhaps the universe is telling us that two is better than three.

-- KentBeck

It's too easy for two to outvote the other in a triple. Pair programming should be consensual. -- SteveFreeman

When two people are coding they both feel responsible for what's going on, when three or more are coding they all feel that it's one of the others that's responsible. -- StephenHutchinson

Here we have been known to do both PairProgramming, and TriProgramming on occasion. Here are my thoughts on the matter:

PairProgramming:

Is easier to schedule (i.e. easier to find one other person than two other people)

Is less complicated, in terms of the social dynamics involved between the people (2 people = 2 relationships (a-b, b-a) 3 people = 6 relationships (a-b, b-a, a-c, c-a, b-c, c-b) )

TriProgramming:

Is able to come up with more complex ideas quicker, because there are more people feeding ideas back and forth. (see 2 above)

One dynamic that often occurs is two of the three 'get it', sort of, and the third doesn't.. the first two explaining it to the third gets it clarified in everyone's mind, including clearing up differences in interpretation between each of the first two.

-- DjMoon

Sometimes in our outfit, when a pair is struggling over some design problem, they'll draw in a third person as a FlyingDesignConsultant to thrash things out. I don't know whether this counts as TriProgramming, but it seems to work well. -- StephenHutchinson

Moved here from PairProgramming

Why not TriProgramming?

Think about the BasketballMetaphor. A third guy on the court could only interfere with the other two. -- PCP

Maybe TriProgramming is not better than PairProgramming, but what about the comparison of TriProgramming with PairProgramming+LoneProgramming? If you have an odd number of programmers (for whatever reason), is it better to let the remaining one code alone, or form a triple?

Another possibility is PairProgramming + lone person does odd tasks (e.g. administrivia, learning, etc.) and rotate. The lone person is not just wasting time, he is preparing for his next pairing session. This may seem inefficient on the surface, but that may be offset by the fact that you won't have any parallel development, and therefore no check-in conflicts and no merging.