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.