While at SPA 2006, I was talking to someone about pair programming. They said something along the lines of it being difficult to get accepted where they work. Someone else said that they'd not seen pair programming work anywhere. I piped up that I'd never seen it fail. I claimed to have pair programmed with around 100 people. Now I'm a bit more sober (it was a conference, after all), I've been reflecting on whether that was really true, or if I'm just full of ... beer.
When I first heard of XP, I liked the sound of it. Except for pair programming, which I thought was obviously nonsense. I was talking to a friend and ex-colleague, Tim Mackinnon, and he suggested that I suspend disbelief and try it for a few days. What's the worst that could happen? I might not like it for a few days then I could go back to not pair programming if I wanted.
So, I tried pair programming for a few days, pretty sure I wouldn't like it but willing to give it a go. That was late 1999 or early 2000 - I don't remember exactly - I've been pair programming, or cajoling teams into pair programming, most of my work time since then.
There's lots written about pair programming elsewhere; I'll just give a short list of what I've observed (which I'm sure isn't exhaustive).
Benefits:
- It's more productive overall
- You get higher quality code
- It's more fun
- Most people learn more by pairing (even very experienced developers)
- Inexperienced but capable developers learn lots very quickly by pairing
- It's more focused - less surfing, more working
- It's more focused - less gilding the lily, more getting it to work
- It's more focused - fewer dead ends, more working on what really needs to be done
Disadvantages:
- It's more tiring
- It requires a suitable physical environment (e.g. desks you can pair at)
- It's best if everyone works in the same place - remote pair programming can work well, but pairing is better in person
- It's best if everyone works the same times during the day - I've tried pairing on a team with "flexi-time" and it's not as good as having fixed hours
- It doesn't suit everyone
- It doesn't suit all types of work
I've got a bad memory, so I've had a look through my CV to remind me of the projects I've worked on since starting pairing. It turns out to be 14 projects, all with some amount of pair programming - more on what that means later. I've tried to remember as many people that I've pair programmed with as possible (that is, pair programmed with rather than just worked on the same project) - I came up with 85 names - 15 short of my claimed 100 - either I was exagerating (is that possible?) or, more likely, those people have been abducted by aliens who have then erased my memory of having pair programmed with them.
Of the 14 projects I've worked on since starting pairing, 9 used pair programming very nearly all the time for very nearly all the team's production code. The only non-pairing exceptions for those 9 would be quite rare. Of these 9 projects, 1 hasn't gone into production yet, 1 was cancelled for good business reasons, and 1 was an investigation not a delivery. Of the remaining 6 of those 9, all 6 went into production very successfully (although I have to admit, I didn't enjoy them all equally, dispite the success and the pairing).
Of the remaining 5 projects that didn't use pair programming as much, they did have, at nearly all times, some proportion of the team pairing - I would say averaging around half. Of these projects, 1 didn't deliver for various good reasons that I won't go into here, 1 was cancelled, again for various good reasons that I won't go into here, 1 I left before it was due to finish and I haven't heard how it's done, 2 delivered successfully.
To summarise, of the 14 projects, 8 successfully went into production. Of the remaining 6, 1 is still in progress, 1 I don't know the fate of, 4 were cancelled or didn't deliver.
hmmm. That's the big question.
It depends what you mean. I'd say pair programming didn't fail. It can be difficult to assess the real reasons why a project was cancelled or failed. As far as I know and can tell, those projects were cancelled or failed for reasons unrelated to pair programming, but of course, you'll have to take my word for it unless you were on those projects yourself - so I don't think I can prove my claim apart from using the "proof by repeated assertion" technique that I've been practicing over the years.
hmmm. Another good question for which "proof by repeated assertion" might be needed.
There were lots of factors in the success of these projects; good developers, good team and project management, test driven development, continuous integration, refactoring, etc etc. Out of all the factors that lead to success, I'm convinced that pair programming is a significant one.
I've never worked on a team that has tried pair programming and then given it up. I've heard of it happening, on a team very close to me in one case; just not experienced it myself.
I've introduced pair programming at a few clients where some people (both managers and developers) have been resistant. Some of those people have been "fully converted" and now advocate pair programming themselves. Some gave it a try but didn't take to it well, but didn't stop the rest of the team pairing. I haven't been on a project where pair programming has been abandoned.
Writing this article is (believe it or not - stupid me for not doing this sooner) the first time I've gone through all the projects I've worked on since starting to do XP/Agile and done any sort of assessment of them. I'm rather pleased that I have now. I might even do some more.
Posted by ivan at April 4, 2006 9:16 PMWell, I can safely say that the Fixed Income folks here have given it up. Yes, they still talk about it as if they're doing it, but I haven't paired in months... Oh, and our problem rate is increasing...
Posted by: Ivan's Pair March 2005 at April 5, 2006 7:39 AMTwo other benefits I can think of.
1) Decisions get made much faster.
2) You can have a people with very different aptitudes on the team without having people who are good at, say, brainstorming during design sitting idle or holding the team back when debugging needs to be done. Pairing people with different ways of thinking actually allows new viewpoints on the problem.
Hi Ivan's pair - I'm sorry to hear that the pairing has effectively stopped there. One of the difficulties in justifying pair programming is that it's advantages are more clearly seen from a bigger picture perspective that you've got, but many people just don't seem to grasp.
There are cases where not pairing is faster - in the short term - when you don't care about knowledge sharing and the "bus number", you don't care about long term code quality and hence maintenance effort.
There are lots of people who go for local optimizations and miss the bigger picture of how practices effect the whole team and the project over a longer time. That doesn't just happen for pair programming, but also other "best practices" such as test driven development and ubiquitous automation.
Posted by: ivan at April 5, 2006 11:53 AM