Making Pair Programming Work

I just finished the last of my Software Engineering labs today. The chief benefit of finishing the labs is that I get to sleep in for an hour and half twice a week. For all but the first week we’ve been doing our labs in a pair programming format: two people to a machine, working on the same problem, handing in a single lab submission at the end and receiving the same grade. This is the second time I’ve been doing pair programming for a class, the first time being last Spring. I’ve had a different partner, we’ve been using very different tools and in the 9 months between classes I’ve learned a lot as a programmer. This time around pair programming has been a somewhat different experience. It’s reinforced many of the ideas I had about pair programming previously and I’d like to take a look about how my ideas have changed.

The one thing that I’ve come to realize is that you can’t make pair programming work by just making two programmers sit together. Programmers are people too with all that implies. Sometimes two people just can’t get along, especially when it is something highly creative and involves lots of decision making (like programming). In fact, I think pair programming works best for two types of groups:

1. Familiar equals

In this group both people are at similar levels of expertise and know each other to some extent. Ideally they have done some sort of work together and so have some feel for the other’s style. Most importantly, they have to agree to work with each other. In this scenario, one person acts as an editor for the other. One programmer is clearly the driver who writes the code, makes major decisions and also communicates the reasons for the decisions to the editor. The editor has the job of keeping an eye on the code while it’s being created and notifying the driver about any mistakes. Most of the times these will be small things like syntax errors and typos that the driver might make and not notice. But every now and then the editor can see some larger problem (an incorrect design decision, a possible infinite loop, incorrect test conditions, etc). It’s the editor’s job to call out the driver on such errors and make sure they’re fixed. It’s also the editor’s job to make sure the driver explains all important decisions in a satisfactory manner.

In this group, pair programming serves two purposes: reduces errors from carelessness like typos and making sure that any major decisions are thought through and can be explained logical. Communication is key. If the driver doesn’t tell the editor what’s going on and if the editor doesn’t speak up when something is not clear, this method loses most of it’s usefulness.

2. Master and Apprentice

If the members of a pair are of disparate skill level, then it’s essential for the relationship to be made clear to be one of Master and Apprentice. Putting two unequal programmers together on a task together is a recipe for disaster unless it’s made clear that it is meant to be a learning experience. If this isn’t the case, then it’s very likely for the senior developer to feel constrained by having to explain or dumb-down everything and the junior developer will feel frustrated by not being able to contribute. Both of them will feel like they’re wasting their time and that’s not something that anyone ever wants to feel.

But if the teacher-student relationship is made clear, I think this is a very powerful approach to both programming and education. The Master should be able to explain major aspects of his creation to the Apprentice. The Apprentice in turn has to pay full attention and grasp to a large extent what is going on. It is important that the Master be able to keep up something of a running commentary on the code, or at the least be able to answer questions at regular intervals without getting distracted. The Apprentice for his part has to make a conscious effort to keep up with the Master and to make sure that all his questions are answered at some point. The Apprentice must also be allowed to suggest alternatives and improvements and if they are rejected, the Master must give a clear explanation.

Setting up the proper environment for a Master-Apprentice session, especially on a regular basis will likely not be easy. I don’t personally know anyone who has actually done it either as a Master or Apprentice. And most programmers I know are rather solitary. However, I think the benefits could be enormous if it was done with a group of people over a long enough time.

But what about the rest of us?

Unfortunately, it’s not so easy to find a pair composed of familiar equals or a good Master-Apprentice team. Does that mean that pair programming will fail in all the other possible cases? The answer is no. Having someone sit beside you and look at your code while you’re writing code can help if only because it will help you catch small bugs faster. Those savings may seem like little, but they can build up very quickly. The important question is, do those small improvements justify having one programmer just sitting by and not actually producing anything? There’s no cut and dried answer to that question either, it depends on a lot on sort of software you’re creating, what development model you’re using, who your developers are and what state your schedule is in. If you are seriously considering pair programming for your team or class, it may be helpful to do a 2-3 week trial run first to see how things turn out.

Getting the most out of pair programming takes time and effort, but it’s much easier to totally screw it up. Programmers can often be very defensive about their creations and many people don’t like having someone constantly looking over their shoulder. The most important thing to remember is that there can be only one person actually writing at a time. It must be clear that the driver is in control and the observer can’t be interrupting all the time. At the same time, the driver can’t be a jerk and any suggestions made by the observer have to actually be considered. It’s for this reason that I think the skill levels of the programmers have to be matched properly. Secondly, pair programming can’t be enforced as a mandate from up high. Nothing ruins productivity like having to work next to someone you just can’t stand. If pair programming isn’t working, it’s time to break up the pairs, bug rates be damned. Finally not giving programmers enough physical space is a pretty good way to lower productivity. Having two people sitting hunched over a 15″ screen trying while teetering on the edge of their chairs is not going to help. Lots of people have talked about how programmers need to be comfortable and that doesn’t change because one of them isn’t actually writing code.

Personally, pair programming isn’t really something that I would recommend. I’m still a little skeptical about it and I’d rather have someone review my code later than always be next to me. However, I am willing to believe that in moderation and with good pairs there can be real benefits. It’s up to you to decide whether or not you can work in a pair, but I would really suggest giving it a try before making up your mind.

Advertisements

Published by

Shrutarshi Basu

Programmer, writer and engineer, currently working out of Cornell University in Ithaca, New York.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s