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? - Page 2
(A critical look at the book Pair Programming Illuminated)
Matt Stephens and Doug Rosenberg, Software Reality. www.softwarereality.com
And the Winner Is . . .
Aside from the longer-term learning benefits, it seems that the most beneficial form of pairing is with two programmers of roughly the same ability. It’s more likely that the pair will be on the same wavelength and will spend less time disagreeing over things that probably don’t matter that much. Unfortunately, when you consider that 50% of all programmers are below average, it becomes obvious that mixed-ability pairing is likely to be the norm. This highlights the problem that teams of mixed abilities are almost unavoidable. Pair programming makes the issue unavoidable by forcing these people to code together on the same program.
In a non–pair-programming project, the problem is handled effectively through other more natural practices, such as team leading, code and design reviews, occasional (voluntary) pair programming, mentoring, design documents, and so on. With almost all of the problems described in this article, it’s up to the coach to catch and deal with them as promptly as possible. This places a lot of responsibility on the coach (almost as much as the on-site customer!)
Design Documents Reduce Reliance on Pair Programming
Design documents provide a record of design decisions. This makes them particularly helpful for novice programmers to explore the thinking behind the design, as described by the more experienced senior programmers. If the team is becoming lost in a sea of changed minds and refactorings, the design document often helps to remind the team members of why they originally decided to do something in a particular way. There’s usually a pretty good reason.
We discuss the role of documentation in software projects (and how it can lessen the need for pair programming) in Extreme Programming Refactored Chapter 7 [1].
And More Problems
Chapter 7 of PPI (titled "Problems, Problems") discusses several problems with pair programming. We briefly discuss some of these problems here. Although the authors of PPI do offer some practical advice to overcome or help prevent these problems, the proposed solutions either result in high maintenance or rely idealistically on the programmers being constantly aware of all the problems (with advice such as "Just proceed a bit more cautiously"). One problem is that of rushing. Because pairs rotate often, they might rush to finish a task before it’s time to separate. The advice given in Chapter 7 of PPI is as follows:
"If a task must roll over to another pairing session, the task must roll over to another pairing session! Slow down, and do it right together." [2]
The coach would need to be particularly vigilant to spot this problem recurring, because pairs rotate so often. If the problem happens a lot, it may be because the tasks are too big (another direct consequence—evidence of the circle of snakes unraveling. To counter this, the team may need to spend more time planning or designing, or change its process for estimating stories or tasks). Another problem, which we suspect would particularly manifest in teams that publicly laud themselves as "the best team on the face of the Earth," such as the original XP team that worked on the infamous C3 project) is that of overconfidence:
"There may be a feeling that a pair can do no wrong. If you’re working together, you might convince yourself that whatever you do together must be right. Remain cautious and careful!" [2]
The problem of overconfidence would need to be watched for carefully by the coach, who should be aware of this type of problem. She would then need to be able to watch out for the telltale signs and be prepared to act on them when she catches pairs reassuring each other into writing bad code. "Well, I suppose it will do for now—we can refactor it later!" is the typical start of a slippery slope. Another problem is that it’s human nature for people to want to be in control, at least of their immediate surroundings:
"New folks should specifically be paired with mentoring types, lest they feel unwelcome or frustrated in the hands of a partner who wants to make only personal progress. This mentor must also give up control and allow the less skilled team member to drive most of the time. When the mentor is directing most of the activity, it’s better for the trainee to be typing and not just listening. The student might not be assertive enough to ask for the keyboard." [2]
This is, of course, an idealistic approach. As we discover in Rich Camden’s "Voice of eXPerience" account [1], being in control of the keyboard is the preferred option for most people. Rich wasn’t offered the keyboard once in 5 months (that’s not to say that he didn’t get to type, but no one actually offered to relinquish control). If the other person doesn’t speak up, he’s not going to be offered the keyboard. As the previous quote suggests, this is particularly a problem with inexperienced programmers being allocated an experienced partner. Everybody likes to be the driver, to be in control.
Watch Out, There’s a Snake Under the Desk!
The problems we just described must all be watched for and quickly fixed before they lead to other problems. This is a lot of problems associated with one XP practice, all waiting to slip and catch the unwary coach, who must be especially vigilant.
Pair programming by itself can be a beneficial practice, but in an XP project its problems are much more acute because (as we discuss in Chapter 3 of Extreme Programming Refactored) so much else in XP relies so heavily on its correct and consistent execution throughout the project.
References:
[1] Matt Stephens and Doug Rosenberg, "Extreme Programming Refactored: The Case Against XP", Berkeley, CA: Apress, 2003
[2] Laurie Williams and Robert Kessler, "Pair Programming Illuminated", New York, NY: Addison-Wesley, 2002
Agile Software Development Articles
Agile, Multidisciplinary Teamwork
Adaptative Project Management Using Scrum
Opening Communication within a Scrum Team
More Agile Knowledge