DominicWilliams.net / eXtreme Programming


Don't restrict pair programming to difficult tasks

Pair programming is one of Extreme Programming's most beneficial practices, yet seems to meet the most resistance from developers. The most common compromise I see teams making is to agree to restrict pair programming to "difficult" tasks. I think "simple" tasks should either be used to learn pair programming (or other XP skills such as refactoring), or made difficult enough to be worthy of being dealt with by a pair.

Adopting pair programming

Restricting pair programming to difficult tasks is a big mistake for teams that are in the process of adopting and learning XP.

Pair programming is not supposed to be done the same way as solo programming - it is different, and can take a while to learn. Working on a difficult programming task is not a good time to learn new skills - your mind is already challenged, and you need to rely on your existing skills and habits.

Every one should be taking turns pairing with everyone else (switch pairs at regular intervals of half a day). This is especially important at first to avoid the social tension which can develop owing to the team being less experienced wich pair programming. But a difficult task makes it harder to switch often, because until you've also mastered test-driven development and continuous integration, there are few intermediate stages when someone can leave part-way through without being frustrated, and someone else can arrive and get involved easily.

Difficult tasks can be challenging in a fun way, but can also be scary or disagreable. They also go wrong more often than simple tasks. Systematically associating negative feelings and outcomes with pair programming is not giving it much chance of becoming popular or being perceived as an effective way to work.

In some places, some people don't like admitting to finding a task difficult. XP is supposed to promote an egoless, supportive environment, but until the team has reached that state, if asking to pair is equated with failing to manage a task on one's own, pairing is not going to take off.

If you're finding pair programming disagreable or an inefficient use of your time, chances are you're not yet doing it right. Rather than limit its use to difficult tasks, here is what I suggest:

Making simple tasks difficult

Even experienced XP teams that practice, enjoy and recognize the effectiveness of pair programming sometimes agree that certain tasks are so simple that pair programming is not called for. I think these teams might be missing opportunities to perfect themselves and suggest they should treat "simple" tasks as a code, design or process smell.

Pair programming is useful when:

In other words, only mindless, rote tasks which every on the team has already done don't call for pair programming. Unless... mindless, rote and done by everyone? Surely there is some kind of duplication going on! Something can be abstracted out, meta-programmed or automated here!

These tasks should be made more difficult: in addition to carrying out the task, opportunities to remove the need for such mindless work next time around should be identified, prepared for or actually realized. Suddenly the task requires intelligence, involves new decisions and no one on the team has done it yet.

Conclusion

Don't restrict pair programming to difficult tasks. If your team is adopting pair programming, difficult tasks are not the best time to learn. If your team is experienced with Extreme Programming, there shouldn't be any tasks simple enough not to justify pair programming.


First published: 5/4/2007.
Copyright (C) Dominic Williams. Contact.