Pair Programming: It’s In the Planning

Posted By on March 3, 2012


Pair programming, in case you’re unfamiliar with the term, is exactly what it sounds like: 2 programmers working on together on the same problem at the same time. The pair share a single keyboard, usually with one doing the typing (a.k.a. the driver), and collaboratively working out a solution for the task. The idea is that the resulting quality is higher due to a second pair of eyes sanity checking everything that is done. When it works right this can actually increase productivity over two programmers working independently on distinct tasks.

On to the goods published an article titled Pair Programming Considered Harmful? about the pros and cons of pair programming and, more generally, what sort of privacy vs collaboration works best for software developers. It got me thinking about my experiences with pair programming and specifically my experiences in the last week. I’ll get to that in a separate post, but first I’m going to speak about the more traditional experiences I’ve had.

I work for a company that’s had a fair amount of growth and transition from small to medium sized business in the last few years. This creates a much stronger focus on maintainability and scalability of technology. Honestly it’s not just about the longevity of the business either. It’s a simple fact that as more people work on a project it needs to be easier for more people to work on it. In turn this leads to a lot of refactoring, improving our code standards, and exploring ways of working that we hadn’t previously. Pair programming was one of the earliest things we tried. I wouldn’t say it’s always been successful, but we continue to use it and it’s viewed positively in our environment. (A look at the comments on the TechCrunch article suggests other shops have had a lot more trouble.)

Our first attempts had some stumbling to them. The most immediate discovery was that some tasks simply worked better for it than others. This is a difficult item to quantify with a blanket rule but what it quickly led to was people identifying tasks that they felt would work well for pair programming during planning sessions. We were then able to earmark these task and plan around that. These decisions were made due to a knowledge of our code base and our expectations of what would be needed for the task.

The next “obvious” lesson was that the dynamics of pairing could be extremely different depending on the task and the people involved. I remember working on a task involving our ETL system which is completely done in Perl. The developer I was paired with had never worked in Perl. He was a smart guy but I was working in a language I knew well in a code base I was intimately familiar with whereas he had never looked at this code nor used the language, and he was quickly lost. It meant that not only did I need to explain what each function was trying to accomplish but how it could be done with the language. This quickly went from a collaborative process to a training process. Even at that I think it was less effective due to me being the driver. Overall it felt frustrating for both of us. It would lead us to become more aware of the goals of pairing on a task and how it would affect the requirements.

Alluded to in that last story but perhaps not quite as obvious is the impact that can be had by selecting the driver. In a balanced dynamic – skill sets, knowledge regarding the task at hand, experience, and confidence are all relatively equal – this should make little difference. As those vertices move it has a much bigger impact. I’ve seen highly confident developers sit back and ask their partner’s leading questions just to get the results they desire. I’ve seen the less experience lose interest when being an observer. In the earlier example I tended to drive ahead without regard to how well my partner was keeping up. In most cases the “driver’s seat” is an empowering place, but with certain combinations it can create a situation where the observer becomes more of a critic than collaborator.

Based on my experience, I think there’s a few key points to address that help make a positive pair programming experience. They are:

  1. What is the goal? – What task are we trying to complete?
  2. What is the goal? – What are the developers expected to gain from this?
  3. What is the goal? – What is the team/department/company expected to gain?

The first point is important for any story a developer is going to be working on, but in clarifying that question we’ve found it’s easy to identify how well a task will suit pair programming.

The second point helps the developers identify what their roles will be in this pair. Along with the third it helps contextualize the dynamic. Examples of developer goals include assisting with unraveling an obscure bug, learning a new system, cross-training, exposure to new languages, exposure to new problem solving techniques, or simply team integration. Larger goals might include distributing domain knowledge, improving team dynamic or efficiency, or simply elevating the quality of the output.

A pair of developers working together on the same goals can lead to great experiences. A pair of programmers at odds with their expected goals only leads to frustration.

About the author


Leave a Reply