To Pair or Not To Pair

Although I have been using pair programming as a standard practice with my teams since 2001 once in a while I still run into the question - usually asked by an uninformed outsider - whether pairing really makes any sense. The naive view is that it appears that two people are doing the work of one so it doubles the cost for most of the items.

Initially I was extremely adament about pair programming. It's called EXTREME programming after all! Quite some time ago I changed my position slightly. Today, when I start working with a team I make it clear that the default for doing any software engineering related work is to pair with a second person.

Does this mean that the people in the team I work with pair all the time? No, not according to my observations. There are quite a few occasions when people work by themselves.

One such case is if people would like to explore a new technology or tool. Different people prefer different learning styles. And before they present their findings to the team for further discussions most people want to understand enough about a topic before using their colleagues time. This gathering of information could be just surfing the web or reading a book on the subject. But it could equally be running a few experiments on a development workstation.

Then there are the usual other activities that most people prefer to do alone, e.g. email, filling in time sheets (yes, there are still a lot of companies who have them), etc. Also, you might want to call your doctor or spouse or log in to your broker without a colleague sitting next to you.

Unfortunately there seems to be only few studies out there on the subject. Laurie Williams' work is available in different versions, e.g. here and here, and also as a book. But some people would like to see additional researchers/authors who come to similar conclusions. Some studies have been conducted in an academic environment, e.g. with students. These studies are easily challenged when you try to use them in an industrial context. (Please note that I'm not saying these studies are useless.)

More generally I believe that reasoning about pair programming using a linear approach doesn't help. System thinking should be employed. Pairing (or not pairing) affects too many other factors. A simple linear cause-effect thinking tends to exclude critical factors.

Based on my observations and experience I would describe pair programming as an activity that has a positive impact on quality, team learning, soft skills, communication, productivity, innovation, creativity, collaboration, training, and many more. To pick one, let's look at productivity.

While many people believe that productivity goes done (two doing the work of one?), I believe that productivity actually goes up (or at least stays the same). My reasoning for that is - again - manyfold.

First of all, some people confuse body time with brain time. Have you ever walked through a development department where people work solo? Run a little experiment. Peek at the screens of the people and take a note of the percentage of people not currently looking at your IDE (or other work related tool). Now, do the same experiment with a team that uses pair programming as a standard practice. Or even better work with a partner and try to track your stock quotes at the same time... I think, you my point. With pairing there is no way to back out or to just doze off. You're in it full time. The ratio of brain time versus body time is much higher than with solo programming.

Next, a pair can and will be much more adament about the quality of the change set they deliver if they are members of a properly trained agile team. They will merciless refactor trying to use the simplest possible design and implementation to get the job done. They will be creative and innovative in doing so. They will have automated tests in place preventing other people from accidentally breaking their code. And once they have committed their change set they usually can focus entirely on the next task without having to go back to some past work.

There are other factors that are worth exploring, but I'll save them for now. I'd like to come back to them in a future post in this blog. As always, I would be very interested in hearing about your experiences and also about your feedback to this post. Thank you!