Pair Programming Observations

[article]

for me to come up to speed on what you've just developed!"

An XP rule of thumb is: when something is difficult or painful, do it more often until it becomes easier. If integrating is a royal pain, do it more often until you learn how to do it better, or at least until it's apparent you've hit the point of diminishing returns.

If context-switching takes too much time, do it more often. In theory, what this should do is force developers to write better code. By "better" I mean code that accommodates cheap maintenance without adverse impacts on the system.

If it takes me thirty or even ten minutes to come up to speed on a task, yes, there is a thrashing problem. If instead the other developer has followed good design/coding guidelines (small, composed methods, no duplication, appropriate naming, and basic OO design principles go a long way), context switching should take only a couple minutes. Couple that with a test-driven approach, and I can quickly focus on a small amount of detail.

The Numbers
So how many people actively resist pairing? At a large shop of ~300 developers (divided among several teams), about fifteen (5%) developers actively resisted pairing when they embarked upon XP. The rest of the people fell into one of three groups: skeptics, interested adopters, and cows, divided fairly evenly in terms of numbers. After pairing for a few iterations, perhaps five of the fifteen resisters learned to enjoy it. Another five didn't mind it enough to complain any more, and another five hated it even more than before.

Having consulted in a good number of XP shops, my personal experience shows these percentages to be pretty consistent. Based on what I've seen, you'll end up with from one to five percent of developers who can't or won't pair. For most shops, that's one or two people.

Obviously there are always people who don't voice their objection and just go along with whatever is tossed their way. You do want to ensure everyone has a forum for feedback. I've solicited feedback via anonymous 3x5 cards, email, public forums, one-on-one discussions, however I could. Beyond that, if someone isn't going to be honest enough to complain, I suspect it says something about the caliber of that employee.

What To Do With These People
Any shop embarking on XP, RUP, Scrum, or whatever, needs a coach to steer people in the right directions. Engaging in a new process without a coach is worse than trying to play a football game without a coach--at least the football players have done it all before and know some of the things to watch for.

It's a coaching failure if I'm unable to turn some of the pairing resisters around. And usually I can, by working directly with them, by demonstrating the benefits firsthand, and by ensuring that the process otherwise goes smoothly. From my own exposure to pairing, I initially thought it was a bad idea. After practicing it a bit, I didn't necessarily love it, but recognized the benefits and was willing to do it. Shortly thereafter, I began to love what I was able to get out of it.

Most sizeable shops have small adjunct efforts. For valuable resources, one-offs are a great place. There's also the possibility of working on non-production code, such as tools for internal use.

Resisters might still be able to work within a team, as long as they put up with their end of the bargain. Remember that pairing is initially a way of doing continuous review. In lieu of pairing, the

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.