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 :) Bob was hired to replace a programmer I'll call Charlie. Charlie was a nice guy and I felt very bad when he left the company, but I was pretty happy we got Bob. Bob came on and, despite starting knowing virtually nothing about our business, got as much done in a month as Charlie did in a year.
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.
I remember pairing with you fixing a segfault and being in the zone. It's a different kind of zone altogether, I think.
Is it reasonable for a company to really want to potentially inhibit the productivity of Bobs by making them pair?
That depends. How did you measure Bob's productivity with and without pairing? How did you measure the quality and efficacy of his code?
Re:Pair Zones
Ovid on 2004-08-19T04:42:40
I think, if anything, it's a different type of zone. We didn't pair much, but I think when we did, we got stuff done and it was good. There are others that I pair with and it seems almost impossible to get work done. However, it's tough for me to prove this. I can only claim these are my observations and without the resources to do a proper study, I can only make generalizations that I am hard-pressed to back up.
What you're describing sounds like an attempt to pair without the team having agreed to adopt some of the XP practices that support pairing--refactoring being one. If people can say "ooh, that'd be too abstract" and get away with it, or can dismiss refactoring as being out of scope, then, good developers or not, you have a larger problem than just pairing. Pairing is just exposing the problem(s).
As an aside, you missed one benefit of pairing: Pairing keeps developers from getting blocked. In particular, pairing helps avoid "I'm stuck, so I'll just read Slashdot for a few minutes to clear my head." Pairing, done well, provides an active set up cues for little stuff we forget when we're in a hurry, such as "shouldn't we write a unit test for that first?", "how are we doing to test that", or "might a better name for that variable be cleared for the next person who happens by this code?"
Is it reasonable for a company to risk potentially inhibiting the productivity of Bobs by making them pair?
That depends on whether the company is willing to risk depending on Bobs. When a Bob gets too far out ahead of the team, it's often difficult for the team to follow that Bob's thinking or code. The corresponding drag on productivity when someone else has to take on Bob's work can lead to a net lose.
Sometimes, the short-term gain is worth the risk. Startups often rightly depend on a Bob or two, chancing that they'll get a chance to pay off the resulting technical debt once they've built up revenue and can build up the team.
Re:On Pairing
Ovid on 2004-08-20T02:34:30
I think you've hit some key points. I would agree that the team has not bought all of the XP tenets, though to a certain extent, I think it's incumbent upon management to help them along there. Still, if the team isn't entirely sold on the benefits, I think this makes the situation more difficult and means that we either need to find a way to better strengthen our XP practices, or find ways of gaining the benefits that the programmers agree to.
And yes, I did forget about pairing helping to overcomes blocks. I have them from time to time and pairing would certainly be a nice way to overcome them. When I get them (and sometimes they're about absurdly simple problems) I usually grab someone for a few minutes and that helps.
Funny, but my experience is pretty much the opposite. Pairing helps me stay in the zone (okay, Pairing and TDD in combination). Pairing because I get burned out less, if I get tired my pair will start driving. TDD because it makes getting back into the zone very easy because I know exactly what I was doing - making the next test pass.
These are really interesting posts BTW. Have you considered posting them to the extremeprogramming@yahoogroups.com list too? I'm sure people would find it interesting, and you might get some useful info.
Re:Pairing and being in the zone
Ovid on 2004-08-20T02:38:16
I started to write a long reply but I realized that some of what I wanted to say would be inappropriate for a public journal. Suffice it to say that there are other issues and not being able to discuss all of them openly distorts what's going on. I tried to be fair in the parent post, but there's only so much I can do.
And I'm glad you find the posts interesting. I hadn't thought about posting this the yahoogroups list. I'm afraid of being burned at the stake
:) Re:Pairing and being in the zone
cog on 2004-08-20T11:25:51
And I'm glad you find the posts interesting.I, for one, was a little bit shocked when I looked at the parent post and saw how long it was, but it turned out to be a very good reading
:-) Thanks :-) Re:Pairing and being in the zone
Adrian on 2004-08-20T15:03:16
I tried to be fair in the parent post, but there's only so much I can do.I hope it was obvious that I wasn't trying to criticise, just offer an alternate experience. If not, apologies
:-) I hadn't thought about posting this the yahoogroups list. I'm afraid of being burned at the stake.They've not bitten my head of yet!
