Pair Programming Benefits, Part 2 - The Rest

When last we spoke, I discussed some of the pleasant discoveries that I had in my initial pair programming outings. In this post, I'd like to share some of the pain points I experienced, my thoughts on mitigating them, and some additional thoughts on when pair programming might be more or less appropriate.

Brief context: my first experience with pairing comprised about two weeks of regular, all-day pairing. Following that, my partner and I spent some time addressing defects and code reviews (both separate and together). After a few days of Sprint wrap-up and preparation, we proceeded to work on a smaller abstract infrastructure work item for a few days. Finally, once we hit some larger and more straightforward work, we went back to working in parallel (read: separate).

Two Heads Are Better Than One, but Only in Some Respects

1. Being as we were relatively new to pair programming, it was initially awkward to figure out a system for doing things like checking our respective e-mails throughout the day without disrupting the process. I feel as though this could be alleviated by becoming more experienced as pair programmers, thereby establishing a rapport and rhythm for incorporating such distractions.
2. Related to the above, it was mentioned that the fact that we were pairing made other developers on our team more reticent to communicate with us. One factor is that they felt bad "disturbing" the driver, feeling as though this would result in the other programmer sitting around "doing nothing". Also, the navigator often would not be checking communications regularly throughout the day. Lack of communication is, generally speaking, not a goal of development. And yes, that last sentence was, generally speaking, tongue-in-cheek.
3. I moved around less when I was driving than I usually do. This is bad for all of the usual health-related reasons, but like #1, can probably be alleviated through practice. When I code on my own, I try to either get on my feet once per half hour, or work standing for a few hours at a time using a laptop stand. This might just be related to setting up the pair's work space appropriately. While navigating, this wasn't an issue.
4. There is definitely a slight tendency towards groupthink if you have two developers with coincident perspectives. As you may have surmised, the types of developers who decide to pair program without instruction can also tend to do other fun things inside a code base. By "fun", I mean the sorts of things others might call "non-standard", "unintuitive", or "controversial".
5. Riffing off of #4, when our code hit our group's standard code review phase, there were still plenty of things we missed, especially in the areas in which neither of us are particularly strong or focused. For example, different developers within our group having varying levels of focus on code formatting, commenting, framework consistency, UI testing, unit testing, test case preparation, etc.
6. In retrospect, I feel like we missed a few spots where code comments would have been in order. Probably a symptom of working with someone else who understood everything you were doing at the time. A little bit of awareness and discipline should take care of that.
7. Pairing for eight hours a day could be stressful. As I mentioned last time, this isn't necessarily an accepted best practice anyway. We took a full, relaxing lunch each day, which was a big help to this end.

Pair Programming Wasn't Exactly Like the Books Said It Would Be!

My experience with pair programming deviated from the "published norms" in a few other ways that I thought were significant.

1. Many references on pair programming indicate that the driver's job is to focus on "tactical" aspects of coding, while the navigator's job is to focus on the "strategic" aspects. Our process did not reflect this in any way, shape, or form. It was purely collaborative, with all of the minute-by-minute problems being discussed out loud. Perhaps there were times whilst navigating that I was spaced out, considering a solution to a problem, while the driver was busy wrangling getters and setters...but I hardly noticed it as such.
2. Sliding the keyboard between the two programmers - I think this happened maybe three times a week, tops. It was rare to be unable to express a thought vocally. Perhaps a symptom of my partner's prowess.

Thoughts on When to Pair

My limited pair programming experience brought me many new perspectives that I had not even considered prior to trying it.

1. Working on a large, complex task made pair programming worth it. I agree with all of the literature which states that there is little to no benefit to pairing on perfunctory tasks...which makes sense. Ben Northrop, who has more than a few good thoughts, has also made the great point that often individuals spawn the greatest creativity. There is value in distinguishing complex, highly technical tasks from creative, highly abstract tasks. Although, even in the latter case, it's likely that a good bout of pairing is in order after the initial spark has been kindled.
2. Personalities definitely play into the success of the pair. In my limited exposure to such topics, I'd generally identify both myself and my recent partner as extroverted, low-key personalities. When trying to solve a particular code challenge, I found that my partner was often pushing me to use my idea, while I was in turn arguing that we should be using his idea. This is a lower tension resolution than in the inverse situation. Also, obviously, the fact that we don't mind constant dialogue was a big boon.
3. Per #2, I'm not inclined to suggest that everyone on my team should be forced to try pairing as a rule. I certainly wouldn't mind if they try.

Closing Remarks

Due to the heightened, sustained focus that I experienced and pairing's benefits with regards to complex problem solving tasks, I'm pretty sure that we broke even in terms of man-hours-to-deliver. I wish I had a scientific measure for this, but I don't. In addition, I certainly reaped extensive rewards of knowledge dissemination and code quality. Per the above, this is probably not applicable for all pairs nor for all work items.

You can definitely practice pair programming. Working with a particular partner over time will see reduced benefits of knowledge dissemination, and possibly quality, but will increase gelling as well as skill in the more tactical aspects of pairing.

I hope to try more pairing in the future, and with a wide range of other programmers, but I don't expect that I'll be forcing the practice on myself. I'm going to let the opportunities find me. However, my final word - this was one of the most fun and most instructive exercises I've undertaken in a long time.

Thanks for reading!!!