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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by dws (341) on 2004.08.19 0:41 (#33481) Homepage Journal

    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.

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