Slashdot linked off to an old interview with Kent Beck and Cynthia Andres, but it was interesting to see the number of people complaining about the pair programming aspect of XP. Comments like:
Programmers are solo beasts – putting two of these dragons behind one keyboard is asking for trouble.
In the OO Programming course I had this year, they encouraged us to practice extreme programming. Well, it sucked… Everytime my partner and I encountered a little problem and one of us had an idea, he had to explain it to the other, which took at least 3 times as long as just typing it out, which in almost every case made the idea perfectly clear. Suffice to say, after about 4 hours we gave up and just sent each other any files we had edited (of course making sure we didn't work on the same file at the same time).
show a major lack of understanding, not only of pair programming, but of the real world in general. Firstly, there's no reason when pair programming that you shouldn't just type out your idea instead of spending excessive amounts of time waving your hands around and trying to explain it. Code talks and tests talk even better, so use them as a method of explaining. Secondly, and most importantly, if members of your team can't effectively work together and communicate clearly, you have a major problem with your team that will reduce your chances of success in any methodology. In XP such a scenario almost eliminates any chance of success.
It's not just your chances of success that drop when you have a poorly gelled team, it's also your teams morale and work satisfaction. XP should be fun to do. If it's not, you either aren't doing it right or you have a bad team. At Ephox, we tend to spend a lot of our day laughing and generally being happy. That atmosphere comes both from having a gelled team, but also from a number of XP practices that encourage social interaction.
The most significant practice in this regard is sitting together. Being locked away in your own office means that you have to make a special effort to interact with your work mates. Not only do you lose the serendipitous communication of overhearing important stuff, but you also lose the social interaction, the personal touches, that turn work mates into friends. Doesn't that mean that you waste time getting interrupted by talking about what happened on the weekend? Sure does. Does it mean you enjoy yourself at work more, have better developer retention rates and ultimately go faster because happy workers are productive workers? You bet.
Your pointy haired boss might want you to have your nose to the grindstone constantly, but that's because it's notoriously difficult to measure actual productivity so instead pointy haired bosses use number of hours on task as the measure. If they can make you work longer hours and never be distracted from your task then obviously you'll be more productive right? For some things like mind-numbing production line work that is probably true. For work where you need to your brain to be sharp and fresh, not a chance. When you need to think clearly, you need to give you brain a rest regularly and not push yourself to hard. When you do work, it should be energized work.
If you want to be successful with pair programming, you need to get on well with your work mates. You don't have to be the best of friends, but you need to be able to sit and chat, laugh about things and be comfortable around each other. Pairing with a team full of prima donnas and antisocial types would be a nightmare1 so it's vital that you focus on building a gelled team, not just a team who can solve silly math puzzles.
You might think that this is a requirement just of XP, but it's not. It's a requirement of enjoying your work. Even pointy haired bosses know that enjoying your work is important, why do you think they spend so much on company christmas parties and the like? What they don't realize is that one-off events are an insignificant impact on morale compared with having teams that enjoy working together all the time. When done well, those one-off events are designed to get the team to come together, get to know each other and gel better.
At Ephox we consider a gelled team so much a necessity that we make the last step in our interview process going out with the entire engineering team for coffee. There's no technical questions, just sitting around chatting with the people you'll work with. Earlier parts of the interview process will tell us if you have the right skills, but they only give us a vague idea of whether or not you'll fit into the team2. Going out with the whole team though, lets us make sure that there's no major personality clashes with anyone in the team, and that you fit in with the team culture, spirit and people.
So what do you do if you're in a bad team? Either get rid of the antisocial types, or get out yourself and find a team that knows how to work together and have fun. Feel free to send me a résumé.
2 – as a hint, your interview at Ephox has gone well if you and the interviewers have laughed through most of it. As a corollary, if you spend most of the interview laughing and the interviewers don't, you probably didn't do so well. It's bad in any interview if the interviewers spend the whole time laughing and you don't – but we're too professional to do that. ↩