Pair ProgrammingSource: firstname.lastname@example.org and comp.object
Problem: Pair programming is when two programmers work together in front of one screen, writing code jointly. Can its benefits be so great as to justify "wasting" the time of the second programmer?
Vesa A J Karvonen described the importance of team communication achieved by pair programming:
[...] 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."Brooks then goes to state the famous Brooks's law:
"Adding manpower to a late software project makes it later"Now, if the task requires communication, then why not built the communication into the process! Pair-wise programming has the necessary built-in support for communication. Pair-wise programming is a lubricant that can help to overcome the friction caused by lack or overhead of intercommunication. It may not be a silver bullet, but maybe bronze.
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.
Adam Spitz went further to say:
[...] 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"? [...]
Tim Ottinger noted how pair programming promotes learning:
[...] 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. [...]
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