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

Problems with Remote Pair Programming

Expand Messages
  • Brent <me@other-space.com>
    I have an interesting dilemma regarding virtual pair programming. I m trying to do some pair programming with a friend on a hobby project. We both have a fair
    Message 1 of 3 , Mar 1, 2003
    • 0 Attachment
      I have an interesting dilemma regarding virtual pair programming.

      I'm trying to do some pair programming with a friend on a hobby project. We
      both have a fair amount of time in which to program, but we never have more
      than an hour or two per week in which our schedules of free time overlap.

      We've been spending that hour or two with virtual pair programming -- a
      phone and a shared desktop, or IRC and a shared desktop -- which has been
      working well for us, as far as it goes. But we'd like to harness that free time,
      while still maintaining the benefits of pair programming.

      I'm thinking of implementing a policy wherein we meet once a week for (say)
      an hour or two. The first half of our session would be devoted to pair review of
      the code we'd written over the past week. All code written that week would be
      reviewed, and wouldn't make it into the codebase unless it's validated by the
      partner (who'd have full authority to tweak/reject/etc. the code), and all
      Programmer Tests for that code are run by the pair.

      The second half of our session would be spent splitting up Programmer Tasks
      between us, and -- here's the key -- writing the tests collaboratively. So, if I
      decide to take on the Programmer Task for a user logging in, we'd together
      write the tests for that code.

      Questions, based on peoples' experience with pair programming:

      What benefits of real pair programming will be shared by this approach, and
      to what extent?

      How much better would this be than just writing code separately? In other
      words, will the increased overhead of getting together be worth it, compared
      to one or the other of us just writing the code separately?

      (FWIW, we're kindred spirits, and get along very well. I'm definitely a more
      accomplished programmer, and more knowledgeable in this programming
      domain, but my partner is very bright.)

      Thanks in advance for your opinions.

      --
      Brent P. Newhall
      http://brent.other-space.com/
    • Ron Jeffries
      ... C3 had this rule. If someone wrote code over the weekend or such, they would sit with someone and pair review it. The resulting code was somewhat better
      Message 2 of 3 , Mar 2, 2003
      • 0 Attachment
        On Saturday, March 1, 2003, at 10:54:48 PM, Brent <me@...> wrote:

        > I'm thinking of implementing a policy wherein we meet once a week for (say)
        > an hour or two. The first half of our session would be devoted to pair review of
        > the code we'd written over the past week. All code written that week would be
        > reviewed, and wouldn't make it into the codebase unless it's validated by the
        > partner (who'd have full authority to tweak/reject/etc. the code), and all
        > Programmer Tests for that code are run by the pair.

        C3 had this rule. If someone wrote code over the weekend or such, they
        would sit with someone and pair review it. The resulting code was somewhat
        better than completely unpaired code, but not much. It's too easy to get
        the pair just nodding "uh huh", and often too hard to make refactoring
        changes that would have been easy in the moment.

        I notice during working alone so often on ACS that it's definitely not as
        good as it would be with a pair. But by the time I can review with Chet or
        Paul, I'm committed to that code in a way that makes it hard to change its
        direction much. Not impossible, but difficult.

        So my guess: you'll get more work done than if you only worked the hour or
        two together, but the work will be less good than if all of it could be
        together.

        > The second half of our session would be spent splitting up Programmer Tasks
        > between us, and -- here's the key -- writing the tests collaboratively. So, if I
        > decide to take on the Programmer Task for a user logging in, we'd together
        > write the tests for that code.

        Well, of course this isn't quite TDD, as you know. Have you, when pairing,
        been writing all your tests first and then programming? Probably not. If
        that's the case, it will be different in effect from what you have been
        doing.

        But it will be interesting, and if the two of you then work on two related
        things, the tests can serve as a statement of the interfaces. That would
        probably be helpful.

        I predict that you'll write tests that cannot be made to run. I find, quite
        often, that I'll write a test that doesn't include enough information for
        the object under test. Then I have to improve the test setup. That's OK, of
        course. I'm merely observing that it will happen and you'll do the obvious
        thing, fix it and report next time.

        > Questions, based on peoples' experience with pair programming:

        These answers will be, at best, slightly better than random. I'd encourage
        you to try the approach, observe and report what happens.

        > What benefits of real pair programming will be shared by this approach, and
        > to what extent?

        The code will be improved by the review. Reviews always help.

        The author will be more "fixed" in his position than when pairing. His
        views will be more gelled compared to those of the pair. You'll probably be
        able to feel the difference in resistance, from each side.

        > How much better would this be than just writing code separately? In other
        > words, will the increased overhead of getting together be worth it, compared
        > to one or the other of us just writing the code separately?

        I expect you'll get benefit. One question will be whether this works better
        than working alone when you must, and pairing fully when you can.

        Ron Jeffries
        www.XProgramming.com
        Bang, bang, Jeffries' silver hammer came down upon their heads ...
      • Erik Hanson
        ... (say) ... review of ... would be ... the ... Instead of just reviewing code when you re working together, how about refactoring the code you ve each
        Message 3 of 3 , Mar 3, 2003
        • 0 Attachment
          <me@...> wrote:
          > I'm thinking of implementing a policy wherein we meet once a week for
          (say)
          > an hour or two. The first half of our session would be devoted to pair
          review of
          > the code we'd written over the past week. All code written that week
          would be
          > reviewed, and wouldn't make it into the codebase unless it's validated by
          the
          > partner (who'd have full authority to tweak/reject/etc. the code), and all
          > Programmer Tests for that code are run by the pair.

          Instead of just reviewing code when you're working together, how about
          refactoring the code you've each written solo? You'll learn a lot about the
          code, you'll make the code better because of a fresh pair of eyeballs and
          another person's experience and point of view, and you'll pick up some
          programming skills from the other person.

          The downside is that it takes a lot longer to refactor than to review, and
          therefore you might not feel you got a lot accomplished, and you might not
          have any extra time to do the next thing you suggest:

          > The second half of our session would be spent splitting up Programmer
          Tasks
          > between us, and -- here's the key -- writing the tests collaboratively.
          So, if I
          > decide to take on the Programmer Task for a user logging in, we'd together
          > write the tests for that code.

          I agree with what I think Ron said, that you'll find it hard to write a
          bunch of unit tests without writing code to make the tests pass. After all,
          if you write Test A, how do you know what Test B should be until Code A is
          written?

          I could see writing customer tests during this time though.


          Erik Hanson
          (crossing my fingers, hoping my answer is slightly better than random)
          (but I'm not willing to bet on it... :)
        Your message has been successfully submitted and would be delivered to recipients shortly.