One theory of pair programming is that it keeps developers honest. That doesn't seem to be as true as I thought. I've watched a programmer get his tests passing, claim he was finished and then had his pair sit silently, despite the fact that the follow-up refactor was not done, the code needed some serious cleanup and the tests were woefully inadequate. Programmers do not always have the best social skills and many find it difficult to tell someone else that they're not finished or they say it so bluntly that feelings are hurt. Pairing is inherently a social activity. With geeks. What could possibly go wrong? We can sit around and discuss, ad naseum, the intricate details of various Linux distributions, but pairing doesn't just require compensation for different technical skill sets, it also requires compensation for different motivation levels and that requires people skills that some of us simply do not have. This, I think, is an inherent contradiction in the needs of pairing versus the abilities of people actually engaging in it.
We've had programmers fall asleep because they were so bored while pairing. Another programmer was caught playing a Gameboy while pairing. And let's be honest: there are some programmers that no one ever wants to pair with. One programmer, no longer with the company, summed it up quite nicely when he said "Pair programming is great. If I show up with a hangover I can just grab a pair and let him do the work."
Pair programming is a great idea but it is not a cure-all -- of course, no knowledgeable XP proponent claims this. The team I work on has six programmers. Recently, we had a programmer get promoted while we were still one person down. We had, in effect, four people to do a six person job. Hollywood really doesn't care if we're short-staffed, so pair programming got tossed out the window and everyone kept working like mad to get things done. And we did.
Several months ago when we stopped pairing due to workload, our bug rate went up, but this time it hasn't. Instead, our productivity went up significantly and management is, predictably, very happy about this. We've not abandoned pairing. The rule of thumb we use is "grab a pair when you need it." We're having some issues in that we still need to spread knowledge around a bit more, but so far things have worked out very well. I'm very curious to see how our deformed XP variant will perform in the future.
What you're describing sounds like a situation where pair programming was mandated from outside the team.
The team I'm with chose to do XP. We screen for the ability to pair program during the later phase of the interview process. If someone on the team fell asleep while pairing, we'd probably dye his hair a funny color (or an even funnier color).
Re: Pair Problems
Aristotle on 2004-07-12T11:52:54
LOL! That must be an interesting team.(or an even funnier color)
I don't regard XP as a single, monolithic set of practices. All of its parts individually make sense, and they enhance each other, but I don't see a reason that they're all required during every phase of every part on every project. The single most important practice, in my observation (but not experience), is test-driven programming. All else is somewhat optional, or at least flexible, depending on the scope and size of the project and the rest of your methodology.
XP to me seems much like many assertions of what results in good code — a framework of guidelines you should follow until you understand it, at which point you will still follow it most of the time, but will know when to deviate from it. It is much like things such as “use strict and warnings!” and “use CGI.pm!”.
Re:XP: an amalgamation
Ovid on 2004-07-12T15:49:17
I definitely agree with the much of what you say, but I am concerned about XP in general. Pair programming is code review -> don't do too much refactoring without code review -> don't do the refactoring without tests ->don't write the tests without a clear understanding of the what the task is, etc. Pair programming is also knowledge sharing -> with knowledge sharing and more tests, we can write less documentation. XP seems to create certain chains of events that, if not properly understood, can cause people to stumble when they miss some of the links.
The refactoring link might be one of the biggest failures. The design cannot efficiently "evolve" from the code when refactoring isn't being done properly/consistently. I've had to deal with tedious objections from programmers who fail to understand the "don't duplicate" rule. They argue (sometimes correctly) that too much abstraction can detract from the task at hand, but fail to realize that eliminating duplicated code, when done properly, leads to greater clarity rather than greater abstraction. I was also stunned when people objected to me removing many modules with structures as follows:
package Foo::Bar;
use base 'Foo';
1;Those were all over the place because the intent, over a year ago, was to fork the code, but now those were simply useless barriers to further development, had duplicated tests (oh, for inherited tests!) that had to be maintained, but kept 'em because people were afraid of what would break if they were removed (I thought the tests were supposed to add courage for doing the right thing?) I managed to remove them one day by simply doing it as part of a task to "improve performance," but I'm still surprised that people actually wanted that mess. As dws pointed out, though, much of this is due to XP being imposed from the outside on many developers. If they really trusted it, I suspect we wouldn't have some of the silliness that we do. We're so close to having a team that really shines, but that final coat of polish seems to be lacking.
Re:XP: an amalgamation
Aristotle on 2004-07-12T18:23:42
Again, the biggest issue is quite clearly test-driven development. Your coworkers do not seem to have understood why they should write tests. Consequently, they're seeing them as a burden, writing woefully inadequate ones to claim they're done. Inevitably, they have no courage to refactor cruft. It is all pretty obvious, if you ask me.
I really believe that once a programmer understands in his heart why test-driven development is A Good Thing, then all the other practices of XP will be understood effortlessly and will come to him naturally.
It is the single most important lesson of XP and a universally useful approach. In fact, you can always practice test-driven development if you want to — even in a corporate environment with traditional project management methodology. A programmer who Has Understood test-first will do that on his very own if need be, even if noone else follows this practice.
Re:XP: an amalgamation
Ovid on 2004-07-12T18:27:21
In fact, you can always practice test-driven development if you want to...
I turned down one Perl job because the man who interviewed me told me that he forbade programmers from wasting time writing tests
:) Re:XP: an amalgamation
Aristotle on 2004-07-12T19:31:13
That is… I am speechless.Re:XP: an amalgamation
jplindstrom on 2004-07-13T00:53:55
If that guy had a coherent explanation for that idea, it would actually be pretty interesting to hear the reasoning behind it.Re:XP: an amalgamation
Ovid on 2004-07-13T01:01:41
His reasoning was that writing tests meant that you were writing twice and thus were taking twice as long to get anything done. Since the process of debugging requires running the application anyway, that's where testing "should" be done. (No, I don't buy his argument either
:)
Several months ago when we stopped pairing due to workload, our bug rate went up, but this time it hasn't.
Any theory as to why it's different this time around?
Re:Why is it different this time?
Ovid on 2004-07-12T17:35:45
My guess (and I stress that it's just a guess) is that we're not making the sweeping changes we were last time (switching colocations and changing the look and feel of the entire site), nor do we have the deadline pressure. I think the combination of the two last time really bit us. Of course, there's also the possibility that the improved test suite helps. I've spent a lot of time nailing all of the tests to ensure that none of them fail intermittently. Now, if a test fails, it probably really is a bug and is less likely to be ignored. It's probably a variety of factors, some of which I don't know. Basically, don't place your programmers in a pressure cooker and they won't boil over
:)
One theory of pair programming is that it keeps developers honest. That doesn't seem to be as true as I thought. I've watched a programmer get his tests passing, claim he was finished and then had his pair sit silently, despite the fact that the follow-up refactor was not done, the code needed some serious cleanup and the tests were woefully inadequate.
For me this, and the other examples you list, aren't demonstrations of pair programming not providing benefit, but examples of people who are not doing pair programming.
You actually have to do pair programming before you can figure out whether it benefits you, and just because two people are sitting in front of a computer doesn't mean that they're doing pair programming.
If you have two people on stage and one of them is playing a gameboy and the other is asleep then they ain't singing a duet
This may seem like nitpicking (okay - it is nitpicking
There's a difference between:
Somebody falling off a bike isn't an sign that cycling offers no benefits.
Not that I disagree that some people seem incapable of pairing programming because their personalities don't bend that way. In new teams I try my very best not to hire them. In old teams add a lot more code reviews or encourage them to do stuff that doesn't need pairing.
