* SoloProgramming
	* ProjectorProgramming
	* VirtualPairProgramming
	* PairProgrammingAtHome
	* TriProgramming
	* OddTeams
	* PairProgrammingWithMarketingTypes
	* BuddyProgramming
	* BuddyIng - PhranRyder (May 14 2004)

'''Not Quite PairProgramming'''

Another alternate we're trying out. We have a small team (three programmers), and don't feel that we can pair up all the time. Instead, we code in parallel, but have to explain the changes we've made to one of the other programmers before checking the code into source control. And if we do get stuck on a problem we feel is tricky, we do pair up. - KatyMulvey

Absolutely not the same thing. When successfully PairProgramming, every hour the pair spends working together should result in significantly more than two staff hours of work. (At the PairProgramming BOF at OOPSLA 97, someone complained she didn't like it, because she was exhausted afterwards. I think that's actually a good sign! The good news is, you're a lot less tired than you would have been if you'd spent enough hours working by yourself to get the same amount of work done.)

It's possible to Program in Trios, but it takes an almost magic synergy. See the reference to "wedding" above. "Writing in Pairs" is less magic, so often one of us would write while the other two programmed.

When holding a group CodeReview, there's often the presence of an InvisibleReviewer, because more happens in the group than any of the individuals could have done at our desks. That's even more true of PairProgramming.

Katy, I think you are getting one benefit of PairProgramming, namely, having shared knowledge of what the code does. (CodeOwnership belongs to the trio.) But you're missing so much more!  --PaulChisholm

In many situations, the paired programmer need not be programming literate, but problem domain literate. Having the domain expert sitting alongside, the programmer can question the expert immediately regarding something that comes up but isn't apparent until the code itself is being written. To answer several "what if" situations. As a corollary, the expert can have the programmer explain what is being done, and comment on whether the programmer is going down the correct path or has perhaps made a wrong assumption.

This closeness can help clarify muddy parts of a spec, and burn through the intentions of the problem. It tends to speed the entire process up. --anon

Just a few days ago, I discovered JUNIT and I'm eager to try it at work.  If I do the UnitTest''''''s while the developer codes, does that count as PairProgramming?

Even though
	* We are not literally working on the same module
	* It is not literally simultaneous.  I may be coding for a unit s/he wrote a few hours ago

--CayteLindner

It isn't PairProgramming. The writing of the tests informs the code, and vice versa, minute-by-minute. This isn't to say that what you describe is a bad practice, it just isn't PairProgramming.

----

'''Pair Non-Programming'''

A variation on the theme of PairProgramming was noted in a Wall Street Journal article written by Scott Kilman, titled "Monsanto CEO Races to Build Crop Biotech Power", (WSJ, p. A6, May 13,1998).  The article describes how Robert Shapiro, the chief executive officer of Monsanto Co., is rapidly changing the company through acquisitions, divestitures, and re-organizations.

Kilman writes, "Mr. Shapiro radically overhauled the old Monsanto management structure that grew up around the chemical business, creating co-executive positions for many of the top management jobs.  Technology and marketing managers are paired together and given equal authority over each other's areas of responsibility  - "two in a box," he calls it.  "Things are moving too fast for traditional management," he says." - PeterMcHale

There must be similar advantages and disadvantages to WritingInPairs and PairProgramming.  Many people ask for help composing an important email or difficult paragraph.  There are also similarities between DocumentEditing and a CodeReview.  Both often use printouts and occur away from a computer.  However, the first is usually done alone (usually with a red pen on paper) and the second is done in groups.  I suppose reviewing code can involve many people without wasting everybody's time because code is much more prone to be buggy and/or need explanation.  Any explanation, of a fix, of the architecture, of a DesignPattern, is likely to improve the skills of all members of the code review.  -- LisaDusseault

----
CategoryPairProgramming