Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

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.

This article is an excerpt from Chapter 6 of the book Extreme Programming Refactored: The Case Against XP [1], by Matt Stephens and Doug Rosenberg. The book provides an entertaining look at some of the flaws behind Extreme Programming (XP), whilst suggesting some alternative strategies and practical techniques to achieve XP's agile goals in a more rigorous way. For this article we concentrate on pair programming - and in particular the book Pair Programming 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 its title, pitches the case for pair programming. However, it also discusses quite openly some of the problems typically encountered by pair programming teams. In this 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-novice pairing." The intention of such a pairing would be to "get the easier job done well, while training a novice programmer." The challenge of such a pairing is primarily that the expert must take on a tutoring role and must maintain extreme patience throughout. If the expert coder slips, then the result is a "watch while I type" session (sometimes called "go make me a cup of tea while I finish this program" syndrome [1]), in which the novice remains passive throughout and the expert is effectively solo-coding. Despite this, there are distinct advantages to expert-novice pairing. In fact, itís probably the one pairing combination thatís worth mandating, as long as the novice is willing and able to learn and the expert is prepared to give up a portion of her day to teach rather than code in full-flow. This combination is certainly 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 both programmers 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 that you can afford to unleash two complete novices, unsupervised, on it. "Unsupervised" is actually the key. Two novices, unsupervised, would likely 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. We feel very strongly about the need for a coach. If you are unwilling to assign the 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-novice pairing could happen quite often. Therefore, novice-novice pairing isnít something 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 novices are 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 leading the 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 feel that expert-average pairing is a problem. The first is that the average programmer truly is average (i.e., the average programmer is likely to stay that way and will never really progress). The second is when the average programmer doesnít interact enough with the expert. The third is when the average programmer 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]

Go to page 2    Back to the archive list

Methods & Tools
is supported by

Simpliv IT Courses

Software Testing

The Scrum Expert