Yet more heresy from Ovid.
You often hear statitics about how great programmers frequently have more than a 10 to 1 productivity advantage over mediocre programmers. I had a chance to see that in action when we hired a programmer that I'll call Bob (he can out himself if he wants. I just didn't ask his permission before rambling about him in my journal
Bobs are hard to find and they should be treasured, once found. Now what would happen if Bob were hired on a team and started pair programming? I'm sure that other programmers would have learned a lot from him. This is why I feel pair programming can be a great leveler: it can even the playing field. Of course, just as it brings up the skills -- and therefore productivity -- of the programmers with lesser skills, so to does this lower the productivity of Bobs. Here's why I think this is.
I'm sure most of us have, at one time or another, heard about "the zone" and how programmers in the zone are very productive and once they get interrupted, take about 15 to 20 minutes to get back into the zone. You have to remember what you were doing, what that special variable is and why, oh why, did you diddle that typeglob? Getting out of the zone can be expensive which is why some companies realize that fostering "the zone" is a good thing.
I have never been in the zone while pair programming.
OK, that's not quite true. I've had some great pair programming sessions where things just click, but the reality of pair programming is frequently one person driving, one person thinking, and both of them cracking jokes and making side comments. That deep "zone" is tough to achieve because the act of pair programming is often a case of continual interruptions. Further, if everyone is paired up except for a Bob and the new programmer who doesn't know the language or the business rules well and Bob is on a tight deadline working deep in the guts of a complicated framework, Bob's productivity is going to drop and that deadline starts looking deadly.
So what are the benefits of pair programming? As far as I can tell, the three primary benefits are:
Item one can be mitigated simply by being willing to hire the best programmers you can find, though in the case of Perl, sometimes that seems difficult. Great programmers, I think, are always willing to learn and if they don't learn it through pairing, they'll learn it on their own. Constant exploration and discovery seems to be their trademark.
Most of the "code review" that I receive while pair programming consists of someone pointing out simple syntactical errors. Sometimes the discussion deals with proper design and when that happens, pair programming is invaluable. However, in one of my first experiences with pairing I pointed out to another programmer that we could refactor out some code that was repeated three times and he told me "too much abstraction confuses people," even though this code was begging for refactoring. Yet another programmer would repeatedly dismiss many of my refactoring suggestions by stating they were "out of scope" of the problem despite it affecting the very problem we were working on. Both of these programmers tend to write solid code, so I was surprised by this, but little disagreements like this seem to pop up a lot.
Still, the code review issue is pretty dicey. Looking at a 500 line diff is never going to be as effective as looking over one's shoulder when the code is being created and understanding why the programmer is doing what she's doing. Further, this lack of continual code review has certainly had a negative impact on our team of six programmers where I work.
Sharing business knowledge is the tricky part. I've yet to work at a company that consistently documents their code. When you really need a customer number but the function in question is copying everything except the customer number, is that a bug or a business rule? One would think that this behavior would be expressed in a test, but tests frequently test what's there, not what's absent. Even running a code coverage report that shows 100% of the code is tested can't prove that the behavior is correct -- tests don't do that. Only business knowledge can really be an accurate judge, though sometimes it's subjective and difficult to test.
Since our team at work is having trouble getting back on track with pair programming, we've considered adopting an idea Ward Cunningham gave me: have weekly "business meetings." In these meetings, one programmer will take the time to explain part of a system and how the business rules impact the code. Now, instead of one programmer learning from another programmer, we can have the entire team potentially learn this information, and possibly even correct misconceptions. This might help alleviate the lack of business knowledge sharing.
This is not to say that we can do away with pair programming completely. We have a new programmer who's off by himself and doesn't get in a lot of pairing and I really feel bad for the guy, but we're not getting a huge amount of time allocated for pairing with him. Sometimes we go out of our way to pair with him, but when we're really busy, he has to fend for himself as everyone pairs up. This is certainly not a criticism of his skills. He simply needs a pair to learn our complex system. At the other extreme, Bobs on our team are going to benefit less from pairing.
I suppose that some might argue that with enough pairing with Bobs we will have the tide lifting all boats. Then the sea monster of reality sticks its head out of the water. Not every programmer is always going to be motivated to do great work and they'll be a drag on whomever they pair with. "Fire 'em!" you say, but simply because someone is in a slump is not an excuse to throw them overboard. It's when they never come out of the slump that "Fire 'em!" becomes appropriate.
Another "anti-tide" arguments stems from programmer turnover. As programmers are transferred to other teams, leave the company, and new programmers are added, trying to make everyone a Bob is like shoveling back the ocean with a fork. Is it reasonable for a company to risk potentially inhibiting the productivity of Bobs by making them pair?
Of course, if some don't have to pair, that will likely hurt morale and I don't think that can be discounted. "Why doesn't she have to pair when I do" can be a tricky question to answer. (How do I punctuate that? Is there a question mark before the final quote mark?) A manager who neglects morale considerations is begging for a mutiny.
In short, I'm ambivalent about pair programming. I've seen great benefits from it, but I've seen problems, too. It's not the panacea that some claim. It's not the productivity killer that others claim. I think there are other ways of gaining many of the benefits of pair programming, but I still haven't figured it all out. The three benefits I listed are tough to ignore.