Loading ...
Sorry, an error occurred while loading the content.

154574Re: [XP] pair programming in 3 people team

Expand Messages
  • Ilja Preuß
    Jul 21, 2010
      Hi Curtis,

      >> >> Personally, I don't like the idea of infrastructure tasks being
      >> >> secondary class citizens. Either a task is worth doing, in which case
      >> >> it's also worth being paired on; or it simply shouldn't be done.
      >> > Ideally, perhaps.
      >> I don't understand your use of "ideally" in this context.
      > In an ideal situation where the numbers always work out, everything could
      > be paired on. Often, however, the numbers just don't work out.

      Ah. But I talked about which tasks are worth pairing on. Not every
      tasks worth pairing will necessarily be paired on, and that's fine. I
      just don't see that a strong preference of pairing on production code
      over pairing on infrastructure tasks actually makes sense.

      >> >> I'm also sceptical of using task boundaries for pair switching. Too
      >> >> much of an invitation to game the system, to me (for example when I
      >> >> just don't feel like pairing).
      >> >>
      >> > Not sure I see a problem here. If you "just don't feel like pairing"
      >> > perhaps it's best if you don't.
      >> Sometimes it certainly is. And I think it's better to make that
      >> transparent to my teammates, instead of just dragging on with my
      >> current task. And I welcome a process that "forces" me to make it
      >> transparent.
      >> And sometimes I just need a "kick in the ass" to start pair
      >> programming, and then actually enjoy it. Probably just a personal flaw
      >> of mine, but it makes me prefer time-based over task-based pair
      >> rotation.
      >> This makes sense. I tried to qualify my comments with "I'm
      > just brainstorming ideas that sound good while I'm typing them." On the
      > other hand, it seems worth trying for a few iterations to see if your fears
      > materialize.

      I did. That's where my preference is coming from. :)

      And, sure, everyone else should try, too. Just sharing my personal
      experiences here.

      >> > If that becomes an on going problem, then
      >> > let's address it. If you "just don't feel like pairing" then I probably
      >> > don't want to pair with you.
      >> Fair enough. Then let's talk about it, instead of hiding it under "I'm
      >> still not finished with this task".
      > If it becomes a problem, then talk. If now and again I don't feel like
      > pairing and want to take on reconfiguring the wireless router for the new
      > office 8011N network, then I should get the chance to finish it without
      > worrying about a timer going off.

      I don't worry about the timer going off. If it goes off and I still
      want to take on the current task alone, I can tell my team mates. I
      like the accountability that comes with it.

      >> > If you want to go futz around with
      >> > "infrastructure work" all day, just think of how much uninterrupted pair
      >> > time the other two will get.
      >> If that's what we want, let's make that decision explicitely, as a
      >> team. Time-based pair switching helps me surfacing this issue.
      > I'll agree that time based pair switching is always the best practice if 1
      > day is an option for the interval ;)

      I'm not talking about best practice here, but about personal
      preference, from experience gathered in one team. Perhaps I didn't
      make that clear enough.

      And from that experience, long uninterrupted pair time is not
      necessarily something to strive for.

      Cheers, Ilja
    • Show all 16 messages in this topic