Thursday, June 25, 2009

Pair Programming != Two Keyboards

At my previous job we pair programmed because we thought we were doing XP. I could go on and on about why we weren't, and perhaps I will in another post as an example of what not to do, but I won't. I want to write about the paring area and one mistake we made: two keyboards and mice at each station. Don't do that. Here's why.

Pair programming is about communication. Two developers sitting at the same workstation solving the same problem in tandem. Two heads are better than one, so to speak. Pair programming works best when the communication is at its highest. If you can't communicate about wanting the keyboard, how good is the rest of the communication going to be.

Pair programming is about roles or 'hats'. There is a driver and a navigator. The driver worries about the language, syntax, formatting, and other low level programming things. The navigator worries about the task at hand, the design of the solution, and keeping the pair on track towards that solution. When those roles are reversed, there needs to be a clear indication. It's a context switch, and the pair needs a little switch time to orient to the new role. The act of passing the keyboard and mouse is the signal that the roles have been reversed.

Pair programming is about cooperation. It's hard to work together in a field where working alone has been the norm. At the risk of leaning on stereotypes, programmers tend to be solitary creatures. Sharing a keyboard and mouse is a baby step towards the cooperation the pair will need to work effectively together.

I'll always remember my supervisor coming to me after a few weeks working with one of the developers in the new pairing area and saying, "It seems like Joe is just not engaged when we pair. Any idea why?" I said because you have two keyboards and two mice. You have yours and Joe has his. He can focus on his set and think about what he'll do when it's his turn to use them, and not on what you are doing. When you both have a keyboard in front of you, the role each of you is supposed to play is blurred.

So if you have two keyboards and two mice in your pairing area, remove one set for a few weeks. Have the pairs pass the keyboard back and forth for a while. Once they get good at it, which can take a long time, ask them how they feel about one keyboard and mouse. Remind them of the things I've written about pair programming, and have them focus on which hat they are wearing when. I predict that once they get good at it, they'll prefer the one keyboard and mouse, communication between pairs will improve, and productivity might even improve as the role each pair plays are made clear so progress towards task completion is accelerated.


John Goodsen said...

I agree with everything. Another nice post. Here's a picture that Corey Haines recently put up that says what your post says in 1,000 words:

David Chelimsky said...

Agreed that Pair Progamming != Two Keyboards, but I'd say that Pair Programming != One Keyboard either.

As you say, it's about communication.

I've personally had great, productive pairing experiences with both one and two keyboards, and with different styles of pairing (driver/navigator, ping pong, etc, etc).

twic said...

Amen to that, brother. Where did this idea that pair programming requires two keyboards come from? Is it just that people have a fundamental unspoken assumption that every programmer has a keyboard, and thus two programmers must have two keyboards? Or was there an early agile project that did it this way, and was copied?

There's a photo of the office of the C3 project, where XP was invented, in 'Extreme Programming Explained'. I see one keyboard and one mouse per machine.

Curtis Cooley said...

Hi David,

Thanks for stopping by and for your comment.

I agree. You can have great pairing sessions with two keyboards especially if both pairs are already adept at pairing.

I think the extra set is a distraction if you are still learning to pair.

When I pair at a station with two sets, I set one set aside. I still find it distracting.