Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Pair Problems 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

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

    XP to me seems much like many assertions

    • 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

  • 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?

    • 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

  • Isn't one of the things with agile methods the reflection, the ongoing analysis of what works and what doesn't?

    Obsiously the pairing doesn't work. What does the team think about that? Is it a problem or a symptom of another problem? Should you try to make the pairing work? Abandon it? Do something else?
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.