The following link is a comment to the article “Eight reasons why extreme programming won’t work in your shop.” and is titled “Pair programming – pleasant for some, torture for others”.
The author of this comment makes some excellent points on why introverts hate pair programming and why extroverts love it. He also suggested that in his workplace, that the introverts did most of the actual programming.
But, there are other reasons why pair programming should not be forced upon developers:
1. Pair programming prohibits flow. According to the book PeopleWare by Tom DeMarco and Timothy Lister, they define “flow” on page 63 as:
“A condition of deep, nearly meditative involvement. In this state there is a gentle sense of euphoria, and one is largely unaware of the passage of time: ‘I began to work, I looked up and three hours had passed.’ There is no consciousness of effort; the work seems to well, flow.”
“Unfortunately, you can’t turn on flow like a switch. It takes a slow descent into the subject, requiring fifteen minutes or more concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption. A disruptive environment can make it difficult or impossible to attain flow.”
So, pair programming makes it just about impossible to enter into a state of flow. Thus, developers won’t be nearly as productive and efficient compared to working alone.
2. A pair programming study published by Arisholm et al. in 2007 indicated that pair programming neither increases quality or reduces costs.
“The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly.”
In an earlier study, Laurie Williams and Alistair Cockburn reported that they found that in exchange for a 15% increase in program development hours, that pair programming improves design quality, reduces defects and field support costs, reduces staffing risk, enhances technical skills, and improves team communications. Other researchers have questioned the techniques and conclusions of this study. For example, this study involved the use of students and not software developers with several years of experience and is thus most likely fatally flawed from this alone.
3. An experienced developer may find pairing with a much less experienced developer slows him down too much and rather dull. A less experienced developer may feel intimidated pairing with a more experienced developer which may result in less participation and less learning.
4. Developers learn by doing. Sink or swim. Less experienced developers usually only turn into great developers by trying things out themselves. Much trial and error is usually required for a novice developer to turn into a master. There really is no substitute for being presented with a problem, coming up with a way to solve that problem, implementing the solution, and then testing that solution. If a great developer is working with a novice, then the inexperienced developer won’t learn even half the skills required to solve the next problem because the great developer will do most of the work. In chess, it is often said that chess players learn more from their mistakes than their successes. The same is true about software developers.
5. Many developers prefer to work alone and find the paired environment cumbersome.
6. Differences in coding style and values sometimes results in conflict. Who is in charge? What if one developer is great at OO while another is better at algorithms or data driven design?
7. Personality conflicts can result in one or both developers feeling awkward or uncomfortable.
8. W. Sargent has posted an article on his blog titled Where Pair Programming Fails For Me. He concludes that pair programming does not work due to split focus, no experimentation, no high notes, no pride in ownership, and no escape.
9. There are times when occasional pair programming can be useful and beneficial. For example, when a new developer comes on board, assigning some one to pair up with him and show him how to check code in and out of the depository, coding standards, how to run the unit tests, how to run the acceptance tests, etc. can be quite helpful to a new developer. Another time to pair program is when there is a difficult bug that 2 (or more) developers are having trouble understanding and figuring out, or when encountering unfamiliar and complex software or hardware with little documentation.