Tuesday, February 8, 2011

When should we be using pair programming (or writing)?

I attended Certified Scrum Master training with Mike Cohn last week. I have been teaching agile and scrum to undergraduates for about six years now and I thought I should finally get my certification. Although I had the "book knowledge" down pat, I learned a lot from the Q&A and from the conversations that I had at my table. This post is the first of two that I will be writing about my experiences.

One of the people at my table was Andrew Mutz, Director of Software Engineering of AppFolio in Santa Barbara. He joined his organization two years ago and has been using scrum since then. I used the opportunity to pick his brains about his experiences. I was impressed by the software development practices that they use at his organization-- Lots of common sense and a good balance between engineering principle and business goals. (They're hiring, by the way.)

We got onto the topic of pair programming. We both agreed that there were many good things about pair programming. Appfolio has all new hires pair for the first three months or so. I didn't mention this at the time, but there are research literature to support some of our intuitions. Laurie Williams, Ron Kessler, and Ward Cunningham had a paper in IEEE Software in July/August 2000 on "Strengthening the Case for Pair Programming." They reported on studies by other researchers and their own work. Pairing increased the effort (person-hours) by 60%, but reduced the timeline (elapsed time) by 40%. Programmers produced higher quality code (pass more test cases), were happier, and were more confident.

We also agreed that not all tasks benefited from pairing. There were some tasks that were so simple (tedious?) that having another pair of eyes was not helpful.

However, we disagreed on the value of pairing on difficult tasks. Andrew argued that the value of pairing diminished with more complex tasks. Consequently, the graph of value vs. difficulty would look like a typical ROC (receiver operator characteristic) curve. This line is shown in blue in Figure 1.

Figure 1: Difficulty of Task vs. Value of Pair Programming

My impression was that the value of programming increased along with the difficulty of the task. This line is shown in green in Figure 1. Most of my direct experience with pairing is in writing and brainstorming research. But it's also based on conversations that I have had with professional developers who use pair programming. It's entirely possible that Andrew is right and I just haven't experience the top end of the difficulty axis.

Our conversation went on and we also agreed that pairing would be less useful for program comprehension, i.e. trying to understand an unfamiliar code base, if we used the conventional model. However, if we could have two people working side-by-side with a computer each, it might be useful to pair. On one occasion, I was working with two students to come up with a research question for a grant proposal. We were sitting around a table, each with our own computer. We went through cycles of brainstorming, critiquing each other's ideas, and doing searches of the academic literature to see what had been done before and to get new ideas. We managed to eliminate a lot of dead ends quickly.

I'm sure that there are other situations that are worth discussing.

What do you think? When should we be using (or not using) pair programming?

4 comments:

catenary said...

One of the greatest benefits that I've seen pair programming yield, in my research, is not about productivity for the task at hand, but about building knowledge resilience in the organization. So if two people know what's up with a very difficult piece of code, chances are that later on one of them will be able to jump in and correct the problem. The more and more team members pair program, the more knowledge resilience their team has, and therefore the better the team can do in the future.

So even if Andrew's curve is right, I would say that that's not the point: you *especially* want more than one person aware of what's going on with difficult code, so problems hurt less later on...

Mausburger said...

Good point!

Students for Integrative Medicine said...
This comment has been removed by the author.
Joe Moore said...

Agreed -- Pairing is not just about solving hard problems, but for sharing knowledge, and better code design.