of Microsoft recently posted about discussions of pair programming on an internal agile mailing list. We’ve just had a large team meeting at the end of the first release of our project and whilst talking through various things, pair programming seemed to be the thorniest issue we discussed. Although I originally started writing this as a comment, it soon got so big I’d figured I’d post it here instead.
The majority of the arguments against were that people felt they were more productive (and thus the team as a whole would be more productive) if people worked alone—that more lines of code were produced. Although I can see how pairing is inherently a slower process than working on your own, I still think that over the medium to long term, you end up working as quickly, but (just as important) more effectively:
1. Knowledge is spread across the team. A couple of projects I’ve been on there have been real pockets of knowledge, a real problem if people leave, or are unavailable to help. It also can impact on the work you’re doing if you can apply your knowledge from other areas of the system.
2. I personally feel much greater guilt about writing bad/untested/sloppy code when in a pair - I guess I’m quite egotistical and so want to be seen to be doing things right. This is also true of refactoring - I’m more critical of the way things are written when working as part of a pair.
3. When working to user stories (rather than very fine-grained specs), you’re less likely to make poor assumptions and end up writing irrelevant code.
4. Learning, learning, learning. I’m still a young guy (despite the grey hairs creeping in) and every minute I spend working with someone is a minute I’m learning. This is important for both technical and business reasons, picking up thoughts on OO and TDD patterns, as well as domain knowledge! To me, this point is also a big motivator, otherwise it would feel very treadmill-esque every day.
Returning to Eric’s post, I think the key thing is that its very much something people have to want to do, it can’t be forced on people.
From the experiences I’ve had I’d say that with people who want to pair it is very beneficial. Both parties share the driving, and both learn. Those who are skeptical can either feel like they’re carrying dead-weight and would be more productive alone, or find themselves just coasting through the session—with the other person being fallible for the same reasons as before: sloppy code, poor assumptions, bad testing etc. It really does need both people to question/push each other, just as one person working on their own can be fallible, so can two people who don’t question each other.
I feel very strongly that pairing has helped me improve as a developer. It’s my responsibility to be a good pairer so that the developer I’m working with sees the benefits it can bring, and see beyond overly simplistic criticisms such as fewer lines-of-code produced.