Problems with Remote Pair Programming

[Brent]

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/


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Ron Jeffries]

Post by Brent
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.

Post by Brent
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.
These answers will be, at best, slightly better than random. I'd encourage
you to try the approach, observe and report what happens.

Post by Brent
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.

Post by Brent
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 ...


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

[Erik Hanson]

Post by Brent
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

Post by Brent
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

Post by Brent
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... :)



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/