I work for a company that does not pair program (at least not in recent memory). However, after listening to some people advocate pair programming, I wanted to attempt it and see whether it could be useful within our company. My boss allowed me to try it out this release, and another developer graciously agreed to pair with me for a couple of weeks. Thus I wanted to provide my initial impressions of the experience.
- We moved faster than a single developer (based on estimates), but we weren't twice as fast. I'm not sure how much more quality the two of us combined added, in terms of things like bugs being found earlier (particularly logic bugs), better designs being uncovered, and better practices being followed, but I suspect that, in general, working together did produce better software. Eventually I'd like to try to do some more objective analysis around this.
- Pair programming absolutely helped with focus. Not only was I able to focus faster (the "activation energy" that Amy once described), but I was also able to maintain my focus for much longer. I'd start pairing, and then two or three hours would fly by without me even realizing it. This improved concentration is great, but it also would be nice to find a better balance, so that I'm not delaying other time-sensitive tasks or tiring out faster from the exhausting demands of long, intensive focus. I was thinking of trying something like the Pomodoro technique, where I’d work for 25 minutes and then break for 5 minutes or work for 50 minutes and break for 10.
- Knowledge transfer seemed to flow seamlessly during our work, as opposed to being a disruptive act (like when a developer has to interrupt another to ask a question). My partner was able to acquaint me with parts of the codebase much quicker than I could have done myself, while I think I was able to give him a better understanding of TDD than he had before pairing.
- It's become obvious to me that pairing demands strict discipline from both developers, and it's pointless to pair if the two agree to cut corners, ignore good practices, or do anything else to compromise quality.
- On a selfish note, I really missed putting on my headphones and listening to 4-7 albums a day. It would be nice to incorporate music into the pairing session. Also, if you use disposable cups like my partner and I did, make sure you each label your cup. And interestingly, I found that my partner was particularly agreeable with my ideas on the day I used a steak night to cut an apple (yes, I was paring while pairing).
Despite neither of us having any experience or much knowledge about pairing, I think our initial attempt was a positive one. I certainly agree with this post, which asserts that you can't force pair programming on a team, as the successful adoption of pair programming requires that the team actually have an interest in legitimately trying it. Pairing is definitely a major change, and I wouldn't want others to be required to do it without them first trying it out and personally approving it. And as for my company, I can't imagine us suddenly adopting pair programming for all development, but I wonder whether there are certain situations that are well-suited for pairing. Perhaps at the start of a release, when two programmers can work together to get one of them up-to-speed on a codebase. Or maybe on a piece of functionality that is complex, risky, or larger in scope, where having an additional opinion and another set of eyes might yield a better design and more quality than a single person could (and then later the two programmers could break out to do smaller, lower-risk tasks on their own). I also think having new hires pair with someone else for a release would be useful, but this is more teaching/shadowing and not really pair programming, where both developers are actively participating.
I had fun pair programming, and I encourage others to at least try it.