Extreme programmers do it in pairs

Pair programming (PP) is one of the more controversial practices of extreme programming (XP). This rule states that two people working together, on the same workstation, on the same task, should write all production code.

Pair programming (PP) is one of the more controversial practices of extreme programming (XP). This rule states that two people working together, on the same workstation, on the same task, should write all production code.

If you’ve not come across this idea before then you’re probably getting tense about now.

In XP we practice PP but we don’t assign pairs; they choose themselves and they change frequently. We work on “stories”, which is our name for a type of requirement.

The customer chooses the stories that she wants built in this iteration. The developers then choose a story to work on. Each story is broken down into engineering tasks by those developers. The developers then choose the tasks to work on and two developers must sign up for each task. Rather than have a manager try to guess who is appropriate for each job, the developers themselves decide which job is appropriate for them.

Developers then start working on their tasks, in pairs. Sometimes one of the pair will be called away to help on another task, so someone else will substitute. This does slow the team down, but not by much, and it has the fantastic benefit of ensuring that everyone in the team gets a good and detailed knowledge of the whole system.

When pairing, one developer will drive and the other will follow. The driver has the keyboard and mouse, and must explain what they’re doing to the satisfaction of their pair. The pair must be able to understand the code being written or it isn’t good enough and must be made clearer. Often the driver will surrender the keyboard to their pair, and their roles will switch for a while.

It doesn’t matter if the skill levels of the members of a pair are radically different (actually, it can help a lot if they are). Juniors can learn a lot from seniors, and oddly enough, the knowledge can, and will, flow in both directions. The code we write absolutely has to be as simple as possible. If a senior is writing code, they’ll be inclined to use more complex algorithms; the junior member of a pair would stop that happening and simplicity would be maintained.

Detractors have two main lines of attack against this idea. The first is that this would cut team productivity in half, and the second is that not everyone can work together in this way (after all, programmers are insular, shy geeks at heart).

First, to counter these arguments I’ll point out that PP works, and has been observed to work on hundreds of projects around the world, from large corporates in the States through to little start-ups in Russia. There are even people doing it in New Zealand. The only difference between their project and yours is that they tried.

Productivity: experiments, studies and experience have shown that team productivity isn’t reduced by PP, but in fact, personal productivity is approximately doubled. The managers out there will no doubt know that if you raise productivity you also raise quality. This is the case here too, but whilst the productivity is doubled the raise in quality is considerably higher.

The gains in quality come from 100% inspection, goal-oriented development and simplicity.

Personality: the personality argument is harder to counter, because it’s fairly self-evident that some people just aren’t team players. First, I’d argue that you’re speculating, and that’s a bad thing. You’re guessing that John, who sits in the corner and doesn’t interact with the rest of the team, wouldn’t be good at this. In fact, John, despite being Welsh, may just thrive in that environment if given the chance. This is in fact the result generally observed in similar scenarios.

However, if you’ve really got someone who isn’t a team player, then you’re going to have to either motivate them to become part of the team or get rid of them. Software development is a team game; if you’re not part of the team, then you’re not playing.

PP has been compared to programming in the nude. Oddly enough, most developers seem to like being nude at work, so they take to PP like ducks to water. The observed pattern is that at first teams will feel awkward, and nervous, then after a few weeks they’ll have settled down and will be working well. After a month they generally refuse to go back to working any other way. After a few months they can’t conceive of working any other way. After that, they simply don’t know how to work any other way, nor can they believe the dark ages existed when they did.

Some have even been known to deny that they ever worked without a pair.

Now, the important question: should you do this or not? The answer is, of course, yes. Why not? What are you afraid of? What have you got to lose? Your projects are already failing at an alarming rate and your customers already hate you — can this internal practice really hurt you? Answers on the back of a $20 note to Bryan Dollery, care of Computerworld.

As always, I’m happy to receive correspondence via email, so if you want to discuss this please do so. You have my address. Use it.

Incidentally, my father was Welsh.

Dollery is a Wellington-based IT consultant. Send letters for publication in Computerworld to Computerworld Letters.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags extreme programming

Show Comments