Pair programming is easily the most controversial agile development practice and in my experience the most frequently avoided. It makes some people pretty uncomfortable.
Just so we’re all on the same page, pair programming means two programmers working together on one computer. Yes really. Normally one codes while the other thinks ahead and around. Or, one drives and the other navigates, swapping regularly. The motivation is higher quality output from the outset.
Pair programming requires working much closer with team mates than most developers are accustomed to. This is both its power and it’s greatest weakness. Working so closely with others can bring otherwise hidden personal issues to the surface. My experience in previous jobs has shown me that pair programming can be so personally challenging for some people that the practice is infeasible for that team. Doing it takes courage and maturity, it requires a healthy environment where mutual respect, humour and humility are all expected. Not to mention minimum standards of personal hygiene! This is quite different from the stand-offish formalism characteristic of many alternatives and this humanistic style sets the bar too high for some. Cowboys, incompetent introverts, control freaks and superhero programmers all resist pair programming. It’s like their kryptonite.
Like culture shocked westerners first visiting Tokyo, unused to the dramatic reduction in personal space one can expect, say, on a commuter train, for some, getting used to the personal invasion that is pair programming is a self-imposed barrier they just need to break through.
Pairing up with different people makes this personal contact a dynamic challenge. There are several axes of individual difference which demand different behaviour. For example there’s the novice-expert axis and the introvert-extrovert axis and people have different natural working styles and favoured problem solving strategies. For example I can often be willing to explore unconventional solution paths which make methodical people a little unsettled. Being aware of that helps me communicate appropriately and change my behaviour where necessary.
Pairing requires bilateral adaptability and the art of compromise.
There are many common anti-patterns that lead to ineffective pair programming. These things are fairly well documented, for example see Pair Programming Illuminated by Laurie Williams and Robert Kessler. It’s worth tackling these problems actively because ineffective pair programming is worse than no pair programming and it’s obvious even to would-be starry-eyed XP fans.
One of the reasons I’ve been thinking a lot about pair programming recently is because I haven’t been doing it for a change. (gasp!) Apart from some time on support and fixing a pile of trivial bugs (not pairing), I’ve been working solo on a front-end feature for Jira 4.0. Solo because our team has an odd number of people right now (wanna job?). It has actually put me in a great position to evaluate the practice of pair programming somewhat objectively.
First the good stuff about not pairing. I have some great new headphones and with the right music I can get into the zone and stay there for hours without needing to coordinate with anyone. I do not have to continually exert effort listening or thinking of ways to express my questions or ideas. I just think and do. That’s refreshing.
But I’m not ashamed to admit it’s a little isolating. Hey, I’m a people person.
The negatives of not pair programming are especially visible when you are accustomed to doing it. While not pairing recently I have become curiously suspicious of the quality of my work. I think it’s good, Is it really good? I’m not gold-plating am I? Maybe this is absolutely the wrong approach. Is there something obvious that I’m missing? I’d better get someone to review this.
All those thoughts are plaguing me in my “step back moments” when the tests pass and I get to wonder about the next move. This wouldn’t happen if I was pairing. I would be in dialogue with my partner; we would have common mind (just imagine Yoda saying that last bit).
Pair programming can really help in making a team gel. Spending time together – not just in pair programming but in other activities like sharing a meal or social event during work time help teams to gel. So while there are many reasons to practice pair programming, it’s not the only way to get these benefits. Code review is an obvious alternative for many of the same benefits. Marketing may want to break my arms if I don’t mention Crucible at this point.
So if you’re not improving the quality of your code with pair programming, then I’d hope you are doing code reviews because there really isn’t much disagreement in the industry that this is a very well known and effective method of ensuring quality software development. Atlassian development teams do either one or the other, or sometimes, like in Jira some of both.
Using a tool like Crucible for code reviews has some advantages over pair programming, such as record-keeping and working across distributed teams and time zones. Pair programming has some advantages over code review such as swapping keyboard shortcuts and shell one-liners and helping a team to gel.
So if you have a business case for better quality software then remember: two heads are better than one!