Click here to view the complete list of archived articles
This article was originally published in the Winter 2003 issue of Methods & Tools
Will Pair Programming Really Improve Your Project?
(A critical look at the book Pair Programming Illuminated)
Matt Stephens and Doug Rosenberg
Software Reality. www.softwarereality.com
This article is an excerpt from Chapter 6 of the book ExtremeProgramming Refactored: The Case Against XP [1], by Matt Stephens and DougRosenberg. The book provides an entertaining look at some of the flaws behindExtreme Programming (XP), whilst suggesting some alternative strategies andpractical techniques to achieve XP's agile goals in a more rigorous way. Forthis article we concentrate on pair programming - and in particular the book PairProgramming Illuminated [2] by Laurie Williams and Robert Kessler.
Pair Programming Illuminated (we refer to it as PPI for the rest of this article), not surprisingly given itstitle, pitches the case for pair programming. However, it also discusses quite openly some of the problems typically encountered by pair programming teams. Inthis article, we focus on some of those problems and examine how they may affect an XP project as a whole.
Problems with Pairing Different Categories of Programmer
PPI divides programmers into different categories and then discusses the effects of the various combinations thereof.The programmer categories are novice, average, expert, introvert, and extrovert.The pairing combinations discussed in PPI, with a chapter dedicated to each, are as follows:
- Expert-expert
- Expert-average
- Expert-novice
- Novice-novice
- Extrovert-extrovert
- Extrovert-introvert
- Introvert-introvert
Because pairs are meant to rotate frequently, these various combinations will resurface often in a team of mixed abilities.Thus, in small teams (which is likely, given an XP project), it would be difficult to keep "problem pairs" apart.
"Go Make Me a Cup of Tea" Syndrome
What happens if you pair up a newbie programmer with an expert? This is described in PPI as "expert-novicepairing." The intention of such a pairing would be to "get the easierjob done well, while training a novice programmer." The challenge of such apairing is primarily that the expert must take on a tutoring role and mustmaintain extreme patience throughout. If the expert coder slips, then the resultis a "watch while I type" session (sometimes called "go make me acup of tea while I finish this program" syndrome [1]), in which the noviceremains passive throughout and the expert is effectively solo-coding. Despitethis, there are distinct advantages to expert-novice pairing. In fact, it’sprobably the one pairing combination that’s worth mandating, as long as thenovice is willing and able to learn and the expert is prepared to give up aportion of her day to teach rather than code in full-flow. This combination iscertainly better than novice-novice pairing, which even XP evangelist Ron Jeffries thinks is a bad idea [2].
Laurel and Hardy Take Up Pair Programming
The intent of a novice-novice pairing combination is described in PPI as follows:
"To produce production code in a relatively noncomplex area of the project, giving valuable experience to bothprogrammers in the process." [2]
If you’re considering such a pairing, it’s important to ask yourself which part of your project is unimportant enough thatyou can afford to unleash two complete novices, unsupervised, on it."Unsupervised" is actually the key. Two novices, unsupervised, wouldlikely produce code that isn’t exactly production quality. Luckily, PPI has the answer:
"There must be a coach, instructor, or mentor available to answer questions and also to help guide the pair. . . .Wefeel very strongly about the need for a coach. If you are unwilling to assignthe mentoring task to some expert, then you need to understand the limitations of the asset being produced by the pair." [2]
In XP, this responsibility would fall into the lap of the person (or people) performing the coach role.
As with the other pairing combinations, pairs rotate so frequently that in a team of mixed abilities, the novice-novicepairing could happen quite often. Therefore, novice-novice pairing isn’tsomething that can easily be controlled: It just happens, almost by accident, several times a week. The coach must be fully aware of the fact that two novicesare currently pairing at any time, and the coach must be available to guide them and correct their mistakes. In practice, to combat the proverbial blind leadingthe blind, there’s a risk that the coach may become fully occupied with mentoring one particular pair anytime two novices pair up.
Carrying Your Pair
Similar but less extreme problems occur with expert-average pairing. PPI describes three situations where the authors feelthat expert-average pairing is a problem. The first is that the averageprogrammer truly is average (i.e., the average programmer is likely to stay thatway and will never really progress). The second is when the average programmerdoesn’t interact enough with the expert. The third is when the averageprogrammer doesn’t seem to "get it" and keeps asking the same question over and over:
"This can leave the expert frustrated and can reduce the ability of the pair to complete the task." [2]