All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

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).

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.

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,

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 effortles

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:)

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

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 p