Pairing up for programming

Pair programming is one of the most contentious practices within Extreme Programming - both supporters and detractors can become quite emotional. So what is pair programming, and why do people become so emotional about it?

Laurie Williams describes pair programming as “a style of programming in which two programmers work side-by-side at one computer, continually collaborating on the same design, algorithm, code or test”. From this description it should be clear that pair programming is about more than simply the typing of the program itself, and I personally think that “pair development” would be a much better description of the activity.

Pair programming is not about one person simply watching what another person is doing– in effective pairing, the partners are often working at different levels of abstraction, one person concerned with the nitty gritty details of writing code to support the immediate goal, the other thinking of the big picture and of what to do next, and the partners are switching between these roles frequently. It’s an intense, rigorous and often tiring activity, that creates considered, high quality code.

The emotion quotient
Most of the emotion associated with opposition to pair programming arises because pair programming challenges the common social conventions of software development.

The traditional view of programming is that it consists of long periods of time spent in isolation, during which the programmer enters a “flow” and only interacts with the computer and their own mental models. As a result, programming has tended to be more appealing to introverts who liked to minimise social interactions, and less appealing to extroverts who wanted to collaborate minute-to-minute.

Certainly these are generalisations, but it’s important to acknowledge that there are programmers who simply don’t want to work side-by-side with someone else, and whose job satisfaction will certainly be affected by something like pair programming.

Opposition to pair programming also takes less emotional expression, generally framed around the idea that having two people working at one machine must inherently take twice as long as having them working independently and then merging their work.

This would certainly be true if the limiting factor in software development was how fast we could type programs, but as Kent Beck has observed, if this was the case we’d give every programmer a copy of Mavis Beacon (touching typing tutoring software).

I can’t touch type myself, and I’ve never asked someone their typing speed in an interview, so it’s doubtful this is our primary constraint. Rather, software development is an intellectual activity, which benefits from clarity of expression and the collaborative development of ideas, and pair programming helps in both these areas.

Another misconception is that the success pair programming should be measured solely in terms of the quantity of software that’s produced. When two people partner there are at least three outcomes:

• the software
• shared understanding of the application (the business domain, the design and the implementation)
• skills transfer

The proportions of these change depending on the balance and dynamics of the pair, but all three are usually present to some extent. When an experienced programmer pairs with a novice, the pair may not produce any more software than the experienced programmer might have produced alone, but the novice will certainly have learned a great deal about the application and about programming in general.

The sum of two
Compare this to leaving the two to work independently – we might get more software (though we might want to be very cautious about the quality of the novice’s work), but we get very little knowledge or skill transfer. If we have these two people on the same team, pairing seems to be a preferable way to spend their time.

On the other hand, two experienced people might find that there’s little skill transfer involved in their pairing, but that having them working at different levels of abstraction on the same problem lets them produce a solution faster, with fewer defects.

Another objective of pair programming is to spread knowledge of the application design and implementation as widely as possible.

This is achieved by rotating pairing, so that everyone on the team pairs with everyone else over time, and any particular part of the application is worked on by as many people as possible. In this environment, bad code doesn’t live very long because it’s exposed to many sets of eyes (which is similar to one of the principles behind open source development), and when design sessions come around the team benefits from everyone’s contributions, without needing to rely on just the one person that’s familiar with some particular part of the application.

There are also a number of other benefits to pair programming:

• immediate, continuous code review.
• working with someone increases accountability and discipline. It’s much harder to be slack when someone is watching!
• two programmers are unlikely to have the same weaknesses or blindspots, so we get a strong solution.
• pairs spend a lot less time going down blind alleys, since one person in the pair inevitably gets bored and wants to ask for help.

The last two points in this list are particularly true when pairs are rotating regularly. Of course, there are plenty of ways to do something that looks like pair programming but that fails to achieve, or subverts, these benefits.

If you don’t rotate pairs then you get programming cliques, and minimise knowledge and skill transfer. Some companies use pair programming as an excuse to eliminate personal space (we only need one desk and computer for every two programmers, right?), which ignores the human needs of programmers.

Expecting programmers to pair eight hours a day is also unrealistic – the continual interaction of pairing forces precision and clarity, but is also tiring, and there are always non development tasks to do as well.

Empirical evidence tells us that pair programming is an effective technique for improving software quality and lowering development time, but it’s not suitable for every programmer, and it needs to be implemented in a considered manner to be effective.

Steve Hayes is the Software Development Manager at Internet Business Systems (IBS). IBS provides agile methods consulting and development services, and browser hosted solutions to the financial services industry.