I've recently just had my first experience with serious pair programming, so I thought it would be a nice opportunity to share some of my initial impressions of the practice. Overall, my takeaways were overwhelmingly positive, but those came along with some interesting perspective shifts and a few caveats.
I’m going to detail the particulars of my environment and some of my positive takeaways in this blog post, and then provide a separate post (Part 2) to exposit some of the downsides, some input from fellow non-pairing developers on my team, and some thoughts about when pairing may not be appropriate.
Why Pair Programming?
I currently code in an Agile environment that does Scrum very well. We have knowledgeable management, involved product owners, and communicative business units. Amongst the developers, there have been rumblings about trying pair programming, but not everyone wants to try it as an "official" policy. So, when another PP-philic developer and myself ending up getting complementary portions of a large User Story, we decided to try pairing the overall work instead of doing parallel development and then hooking into each other's code later.
I am fortunate in that the members of our team are more or less allowed to decide how to approach our own work (would that everyone should be so lucky!). So long as delivery time and quality of the deliverables don't suffer, and as long as we're not making other peoples' jobs harder, then all's well. Public consensus seemed to indicate that quality would benefit from pairing, but that construction delivery time in terms of person-hours can increase, ostensibly with the benefit of long-term cost savings. Fortunately, in my case, we ended up not having trouble on either front.
Brian Gray taught me that stock photos are awesome.
The Nature of the Pairing
There are various recommendations floating around about strategies for managing pair programming workflow, some of which suggest regular rotation of pairs as a best practice. The reasons are generally two-fold. First, rotating provides maximal knowledge dissemination throughout a team. Secondly, there is considered to be a decaying benefit to having the same two people work together regularly over a long period of time, presumably due to the fact that those two people will eventually converge on a mutual understanding which limits the efficacy of having two separate outlooks into the coding process. In an unrelated note, I need to learn to write shorter sentences.
Throwing all of those cautions to the wind, we more or less coded together for eight hours a day, every day, for two and a half weeks straight! There were a few factors contributing to this:
- We were the only two developers pairing at the time.
- Neither of us had other deliverables that we were working on in parallel.
- The excitement of pair programming for the first time provided excess energy.
- We had a sweet, giant monitor to work on. Value of this not to be underestimated, as it increased personal space.
Immediate Benefits
There were a few things that didn't take me very long to appreciate about the pair programming process.
- Perhaps the most unforeseen benefit is that I was sustaining a high level focus for longer periods of time through pairing than I generally can when working alone. I was pretty much "in the zone" all day long. This wasn't achieved through headphones and trying-to-ignore-emails, but rather through a sustained, engaged conversation. It certainly doesn't hurt that I am extroverted (more on that next time). In addition, when I was driving, I spent a much lower percentage of my time doing things like tweaking iTunes playlists and checking e-mails.
- When I wasn't driving, my attention to detail (à la inattentional blindness) was definitely enhanced. I was regularly and consistently noticing things which I regularly and consistently do not notice when I am writing code. See Mechanism 2 in Stuart Wray's paper. Note that I didn't read Stuart's paper until after having paired, and immediately identified with this effect.
- The sustained knowledge transfer that took place over these initial weeks was astounding, and energizing. Though I was indubitably the more junior of the developers in this pair, I was able to contribute domain knowledge, a few development-environment tricks, and the occasional code/pattern suggestion while also providing an additional eye when not driving. I feel as though these contributions were significant, because they made pair programming feel much different than mentoring. In return, I got a hands-on look into a skilled developer's work process. That in its own right was roundly instructional and a huge perspective-stretcher.
- We delivered our work on time and in good order. The work we were doing was relatively complex, which definitely contributed to making pair programming a more effective choice. Again, more on that next time.
- Having two developers who were both excited to pair, and who enjoyed it throughout the process (at least, my partner claims he didn't hate it...) was a big deal. We didn't experience any of these potential issues in the slightest.
- For me, PP did, indeed, feel like "continuous code review". I'm not sure everyone feels this way, but for me that felt like an awesome thing.
...in short, most of the benefits described in the summary of this NCSU paper.
Go team!
The Bad?
Like I said, it wasn't all roses and defect-free code. There are some easy-to-spot areas for improvement, both within the process and within myself. Also, my partner and I had some matching thoughts about when pairing would not be effective, and why it worked for us in our particular situation. Mix that together with some thoughtful outside perspective from our teammates, and there's a well-balanced Part 2. Stay tuned, and thanks for reading!
Bonus Humor, Free-of-Charge
One of my Summa compatriots showed me this when they heard I was pairing:
http://www.youtube.com/watch?v=u8qgehH3kEQ
In case you were wondering, that's pretty much exactly how it plays out in practice.
