'''Moved from PairProgramming:'''

This was called "Programming In Pairs" in its first published description (by JimCoplien; see '''Historical Note''' below). It's more commonly called PairProgramming these days, notably by the ExtremeProgramming community.

'''Context:''' You have several people working on a project. Everyone's received the basic training necessary to do the job. Some are (inevitably) more or less experienced than others. You have PairProgrammingFacilities.

'''Forces:''' You want to get more done than your most productive person can do. You want your less experienced people to learn from your more experienced people. You want to structure your organization to avoid needing "n squared" communications channels.

'''Therefore:''' Pair up your people. When applicable, each pair should have a relatively experienced and a relatively inexperienced person. For work being done at a computer, put the relatively inexperienced person at the keyboard, so everything the experienced person says has to flow through the novice to the computer. The point is not for the guru to dictate to the greenhorn; on the contrary, putting the novice at the keyboard is meant to keep him or her more in the loop. When (as happens occasionally) that doesn't provide enough bandwidth, the experienced person will say, "Let me drive" (that's not a prescription, that's what's frequently said), and will show something instead of teaching it at a more leisurely pace. When one member of the pair is not following what's going on, he or she can ask to drive.  ''(Warning: This specific approach to pair programming, LetTheJuniorDrive, has been reported as an AntiPattern.)''

'''Resulting context:''' The real power of this pattern comes from the variety of results it supports.

This is a very effective way for a more experienced person to teach a less experienced person. Everything that's being done, and (if Programming In Pairs works) the reasons for doing it that way, are all passed through the less experienced person. The training is extremely relevant, and adapts to the needs of the "student" (and the needs of the project).

Put a less experienced person together with a more experienced person, and the former will be more likely to stretch. Instead of sticking to familiar, comfortable tools and techniques, he or she will try things he or she only knows a little about, ask dumb questions ... grow. If the less experienced person doesn't volunteer to stretch, the more experienced person is likely to suggest better ways to do something, which the less experienced person wouldn't normally have been exposed to.

Put two people together, and you'll get more than twice as many ways to solve a problem. Each person will have his or her own ideas (there'll be some overlap), plus some half-baked ideas he or she wouldn't normally think hard about, plus the completed ideas of the other person, plus ideas sparked by their other person's, plus ... it adds up fast.

One of the tricks of people working with each other is giving them an opportunity to learn how to work with each other. Programming In Pairs supports that better than trust falls or high ropes (which still have their uses, too).

Two people working together in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or  favorite Web pages; they don't waste each others time.

Two people working together will have their shared time treated by others as more valuable. If I'm sitting at my computer, or just staring into space (thinking hard!), no one will think twice about interrupting me. On the other hand, if I'm busily working with someone, anyone who needs me will interrupt me briefly if at all.

'''In summary:''' Get two people Programming In Pairs, and they'll work more than twice as effectively as one could have.

(Note that none of this is peculiar to software development, though it won't apply to all fields of human endeavor.)

'''Known uses:''' Medical schools have a philosophy of, "See one, do one, teach one." WardAndKent found Programming In Pairs with each other to be one of the highlights of their careers (so far). PaulChisholm found Programming In Pairs with MichaelLindner and LoAnnLindner (nee Reiling) to be one of the highlights of his career (so far). (The three of them traded off Programming In Pairs, and sometimes managed to work the same pattern with three people. Result: 15K non-commentary source lines of C++ in a few months, and Paul was an usher at Mike and LoAnn's wedding. Your mileage will likely vary!)  (See also PairProgrammingTestimonials)

'''Other patterns:''' When Programming In Pairs, CodeOwnership belongs to the pair, not to an individual, which overcomes some of that pattern's downside.

'''Historical note:''' WardCunningham and PaulChisholm found we both HadThisPattern at Steve Fraser's 1994 OOPSLA workshop on teams and objects. During a break, we cornered JimCoplien and effused at him that this belonged in his "organizational patterns" language.

I feel bad about re-writing a pattern from scratch -- that's not hardly in keeping with the best traditions of the pattern community! -- but I've since thought a lot about it, and wanted to share my experiences with it. --PaulChisholm

----
CategoryPairProgramming CategoryPattern