'''Moved from PairProgramming:'''

LaurieWilliams, who got her Ph.D. in Computer Science at the University of Utah, did her dissertation on pair programming. You can find her research at http://collaboration.csc.ncsu.edu/laurie/research.htm .

See AlistairCockburn's Article at http://members.aol.com/humansandt/papers/pairprogrammingcostbene/pairprogrammingcostbene.htm for some hard data to refute the argument from management that PairProgramming is wasteful of man-hours. ( I believe this article is now at http://alistair.cockburn.us/crystal/articles/ppcb/pairprogrammingcostbene.html .)

''Sounds like an interesting concept, have to see how it plays out in day to day operations.''

-----
'''Pairing Statistics'''

In PeopleWare Chapter 10, "Brain Time Versus Body Time," some statistics on the office environment are cited. [Table 10.1, below.] They state that workers spend certain percentages of their working hours working alone, together with another person, and working with two or more people. They go on saying "... it is during their solitary work periods that people actually ''do'' their work."

'''How Developers Spend Their Time'''  (PeopleWare Table 10.1)
	* 30% = Working alone.
	* 50% = Working with one other person.
	* 20% = Working with two or more people.

What about that in the light of PairProgramming? I agree with the authors of Peopleware in many aspects, so I would be surprised that they are wrong in that particular one. One answer might lie in the next section where they contemplate "flow" as the most productive work mode. Perhaps they just didn't notice that a pair could assume flow mode, too. Any comments? (Just an aside: a colleague suggested that flow mode is a myth anyway...) -- HaskoHeinecke [...with additional detail added by JeffGrigg]

''They didn't look for people working together, so they didn't see people working together. PairProgramming is new to lots of folks.''

I haven't read PeopleWare, but I'll note that there are a number of ways for people to work together, and some of them are more productive than others. PairProgramming is a productive way. Sitting around in a ten-person meeting because everybody's scared of the project and nobody wants to take a stab at actually getting work done -- now that's an unproductive way. Does PeopleWare make a distinction between the two?

''Also, at that point in the book they were emphasizing that you need a DistractionFreeEnvironment to be productive when working alone, and most modern office environments do the opposite. -- JeffGrigg''

Note that PeopleWare noticed people spending half their time working with one other person. Some of this may have been PairProgramming, but they were primarily concerned with the MentalStateCalledFlow, and the impact of interruptions/distractions.
-- JeffGrigg

The Flow aspect is another win for PairProgramming. Many tasks that feed best practices require logging or journalling - personal recordkeeping - that break the flow. A 2nd person can accomplish look-aside recording without interrupting the flow state. This saves 15-20 minutes of re-immersion time per interrupt according to DeMarco & Lister. Look at Watts Humphrey's Personal Software Process tasks in this light -- no wonder nobody liked doing PSP!  With Pair Programming, niggling little tasks like PSP record keeping can be done fairly painlessly.
-- BobLee

This dynamic is expressed well by the BasketballMetaphor, which also helps to explain the inverse mathematical relationship to number of programmers available to draw tasks and the number of tasks completed.

The second half of MatrixManagement [currently] contains a good case history of learning to pair despite management ... issues.

----
CategoryPairProgramming