Pair Programming

Related Sites

[...] The extreme things about pair-wise programming are code review and communication. When you do pair-wise programming, you will be reviewing code all the time. Undoubtedly you will also communicate with your pair.

Well, how does continuous communication help, for instance. Consider the following excerpt from The Mythical Man Month by Frederick P. Brooks (ISBN 0-201-83595-9):

"Intercommunication is worse. If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two. If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communication may fully counteract the division of the original task and bring us to the situation of Fig. 2.4."

   Months

     A
     |               +
     | +           +
     |  +        +
     |    + + +
     |
     |
     +---------------->  Men

"Since software construction is inherently a systems effort -- an exercise in complex interrelationships -- communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule."

"Adding manpower to a late software project makes it later"

[...]

Of course you could argue that the traditional design methodologies also address communication in the form of documentation. In my experience, documentation can help when there is no verbal communication or when the readers greatly outnumber the writers.

On the other hand, when you are designing a system in a team of two to four programmers, which is IMO ideal, (excessive) documentation seems to be, in my experience, counter productive.

[...]

Consider the merge sort algorithm. The merge sort algorithm requires O(n) extra space to hold information about sorted subsequences. This extra space is analogous to communication. However, when you sort a linked list, the extra space is already there in the form of links between elements, and no extra memory need be allocated to perform the sort.

Similarly, if you communicate through documentation, you need to produce O(n) (n is the number of documented systems) amount of documentation, which is costly. On the other hand, if you are using pair-wise programming, the communication is built into the process and there isn't that much need to produce documentation. Like in efficient sorting algorithms, not every item need be compared to every other item.

Pair-wise programming is efficient, because it is a lazy algorithm for communication. Instead of producing documentation that may never be needed, you only spend time to communicate with your pair what is actually needed. Not everyone needs to know everything at every moment.

[...] And your alternative is - what? Draw diagrams of the system before it's even been built yet? Have the programmers update the diagrams every time they change something? Hand each new employee a copy of the diagrams and tell them to learn them? Do they have to do it all by themselves, because Pair Programming "causes wasted resources"? [...]

[...] I dearly wish that in all my meager 20 years I'd always started a project (and continued it) being teamed up with the developers who had more knowledge of the domain and the product. Quite a lot of my projects, especially earlier ones, were "sink or swim". Every time I worked with "the revered old one" on a team, I learned and developed at an amazing rate. When left to my own devices, I was more likely to stagnate. If I'd been pair-programming the whole time, I'd be so much more amazingly smart today. [...]

PairProgramming.com

WikiWikiWeb, Programming in Pairs

Ronald E. Jeffries, Pair Programming

Laurie A. Williams, The Collaborative Software Process

Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering