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.

TDD and Fantatics

I don't understand how or when TDD == Fanaticism? Yes, TDD is a high discipline practice, but so is using SCM. You don't just arbitrarily decide to not check in code. Or start the day without pulling down the latest changes. Or not branch/label/snapshot the tree each release.

Yes, TDD advocates can sound like zealots, and that's OK.
We sound like zealots because we've done TDD long enough to get good at it. We are good enough at it to see the benefits. And it took a little longer than half a day to get good at it. We remember the code we wrote and read pre-TDD, and we prefer the code we write and read now with TDD.

I've been an XP consultant/coach for 8 years now, and these sorry assed excuses about how TDD doesn't scale, or my process/project/team is unique and it doesn't fit, or I'm such a bad ass programmer that I don't need no stinkin best practice telling what to do, are getting really old. To be completely honest, they all have a slight aroma of laziness to me.

There are a lot of best practices and processes out there that I do not do or do not advocate, but that's all I do. I don't go out of my way to bash them or the people who find them valuable.