Experiences with Pair Programming

One of the central tenets of Extreme Programming is that developers should never write code on their own, preferring to work in pairs. This is called Pair Programming. The basic concept is that the pair is better able to spot each others mistakes, and help find the simplest solution.

Pair programming has its sceptics. It really does depend on having an active conversation between the two developers. What it can't be is one person typing and the other watching. When I first started pair programming, that's what it was like. It was extremely boring. Boring to the point that I actually fell asleep watching this other developer type code. There's nothing more embarrassing than drooling on another person's desk.

But I kept trying. As we learned how to work together, we found several benefits. We did spot each other's faults. Coding/design oversights, off-by-one errors, etc. We caught a lot of them. However, the most telling point was when another developer and I were fixing a bug. He looked at me and asked "Should we write a unit test for this?" We both quickly came to a very important realisation. If it had been either of us on our own, we wouldn't have written the unit test, we would have tried to fix the bug without the test, and moved on. However, since we were sitting beside someone else, we couldn't talk ourselves out of it. We wrote the test, and solved the problem quicker for it.

That single incident convinced me that pair programming is a great way to enforce a "team value set". Peer pressure works really, really well in small groups.

The other thing that I noticed was that when it came time for me to leave employment with that team, I nothing to hand over. This didn't mean that I didn't achieve anything. It just meant that there was at least one other person out there who knew what I knew.

I'm now back contracting with another organisation and I see a lot of problems that might be made better by a little peer pressure. The build system is slow, agonisingly slow, and it's gotten slower over the past year. The systems aren't maintained in any semblance of order. If you use a machine, you can't expect that the system will be runnable, or even that there will be a set of development tools waiting for you. What does the team do? They ignore these "broken windows" moving on to other systems - to the point of avoiding faults reported by specific customers!

How would the peer pressure offered by Pair Programming help? Well, I would expect that it would become a lot harder for a developer to put something in the "too hard to do drawer" when there's someone sitting beside them. As each team left the systems better than they found them, the problems would gradually sort themselves out. This fits in with another mantra that I've learned recently, "No broken windows"[5].

I was very interested in understanding why pair programming helps peer pressure work. I did a quick google search and turned up some papers. It seems that peer pressure is an area of current research in economics. I didn't really try to understand the math. In [1], they say that the cost of punishment must be low enough for peer pressure to work. If it costs too much to sanction a person for slacking off, they will be left alone. The paper then goes on to demonstrate this using Nash equilibria. This fits in with my experience. Pair programming forces interaction, making it very obvious when an individual is not working to the standard set by the team, allowing immediate sanction by the other team members.

In [3], we have an actual experiment. In that paper, they compared the productivity of envelope stuffers alone, alone with an external indicator of performance, and in pairs. They found that the pairs were the most productive, primarily by improving the performance of less productive subjects.

So, it seems that pair programming works because it helps lower the cost of sanction, resulting in more efficient peer pressure. This may explain why some organisations are reporting that they see more productivity out of a pair than they do out of two individuals. Pair programming isn't a silver bullet. It isn't going to magically solve all of our development process issues. It just might help your developers take responsability for the systems around them. Something to think about.

References:

1. "Peer Pressure in Work Teams: The effects of Inequity Aversion", David Masclet, December 2002. Discusses how the cost of punishment must be sufficiently low enough to allow punishment. Pair programming lowers this drastically. Uses Nash equilibriums. Lowering the cost of punishment increases the frequency and potency of peer pressure.
2. "Social norms and optimal incentives in firms", Steffen Huck, Dorothea Kubler and Jorgen Weibull, 8 October 2001
3. "Clean Evidence on Peer Pressure", Armin Falk, Andrea Ichino, January 28, 2003.
4. "Team Size and Effort in Start-Up-Teams ­ another Consequence of Free-riding and Peer Pressure in Partnerships", Uschi Backes-Gellner, Alwine Mohnen, Arndt Werner, January 2004
5. "The Pragmatic Programmer: From Journeyman to Master", Andrew Hunt, David Thomas, 1999