Question on pair programming to the authors

[R. M. Menon]

I have a simple question. How effective or ineffective XP would be if pair programming is removed from the practice. Having practised it myself, having attended Kent Beck's seminar and also having read his book, I like it but I also see other people's opinion and understand the objections. So my question is:
Can we eliminate or have a revised version of pair programming when practising XP?

[James Shore]

Hi R.M.,

Good question. The short answer is yes, you can remove any of XP's practices (including pair programming) and still be successful. The trick is that you have to understand what the practice provides and why it's important. Then, rather than removing the practice, replace it with other practices that fill the same needs.

I think the best way to gain this level of expertise is to do XP "by the book" for several months and see how everything fits together. In our book, we help readers along this path by providing a discussion of alternatives for each practice. Here's what we say about pair programming:

Alternatives

Pairing is a very powerful tool. It reduces defects, improves design quality, shares knowledge amongst team members, supports self-discipline, and reduces distractions, all without sacrificing productivity. If you cannot pair program, you need alternatives.

Formal code inspections can reduce defects, improve quality, and support self-discipline. However, my experience is that programmers have trouble including inspections in their schedules, even when they're in favor of them. Pairing is easier to do consistently, and it provides feedback much more quickly than scheduled inspections. If you're going to use inspections in place of pairing, add some sort of support mechanism to help them take place.

Inspections alone are unlikely to share knowledge as thoroughly as collective code ownership requires. If you cannot pair program, consider avoiding collective code ownership, at least at first.

If you'd still like to have collective code ownership, you need an alternative mechanism for sharing knowledge about the state of the codebase. I've formed regular study groups in which programmers meet daily for a timeboxed half-hour to review and discuss the design.

I'm not aware of any other tool that helps reduce distractions as well as pair programming does. However, I find that I succumb to more frequent distractions when I'm tired. In the absence of pairing, but more emphasis on energized work.

[ October 31, 2007: Message edited by: James Shore ]

[Shane Warden]

Originally posted by R. M. Menon:
Can we eliminate or have a revised version of pair programming when practising XP?

Hi R. M.,

Although I don't recommend it, you can eliminate (or postpone) pair programming while performing the other XP practices. If you do this, you need to find another way to gain the benefits of pair programming. Specifically, you probably need:

* additional and regular code review
* greater discussion of the code and its state to spread knowledge around the team, perhaps in weekly study groups
* more discipline to stay on task while developing
* a greater concern for energized work

I expect that a team performing pair programming will have a smaller defect rate than a team that programs solo, for example, and I expect there to be greater technical debt in the solo team. Nothing else shares knowledge quite as much as promiscuous pairing, in my experience, and it's a bit of a risk to get rid of it.

It's a manageable risk, though, if you know what you're missing.

[James Shore]

Wow, are we in sync or what?