Remote teamwork anecdotes

[Roy Smith]

In article <1hcigpy.13ky51j19u3eevN%aleaxit at yahoo.com>,
 aleaxit at yahoo.com (Alex Martelli) wrote:

> And even if I'm wrong, and a Joe Supercoder I've never met
> works best with 3 days a week of solo effort, 3 days of solo coding plus
> 2 of strong in-person interaction is NOT the same thing as, say, 3
> _weeks_ of solo coding plus 2 of close in-person presence.

It's not hard to imagine somebody locking themselves in a cave, coding like 
mad for a week, and producing reams of working code.  What *is* hard to 
imagine is that somewhere along the line they didn't get off on some 
bizarre design tangent and what they produced is reams of code that works, 
but does the wrong thing, or in the wrong way, or just plain isn't what we 
needed.

I think the real advantage to pair programming is that it gives you lots of 
small course corrections, before you're emotionally invested in The Wrong 
Thing.  We sit down together, I come up with a brilliant idea, and you 
shoot it down.  We argue about it for a while, and 10 minutes later I 
(hopefully) see the error of my ways and we set off again in the right 
direction.  Contrast that with me showing up with a week's worth of code 
and you pointing out a fundamental design flaw I made four and a half days 
ago.  By this point, I've got so much invested in the code, I'm more likely 
to just dig my heels in.  It's just too painful to admit at this point that 
everything I did last week is garbage.

Pair programming is not easy.  One of the hard things is to learn to let 
go.  I can't tell you how many times I've been sure I'm right, but decided 
to let my partner have his way because otherwise we'd make no progress, 
only to have him volunteer 15 minutes later, "Hmmm, maybe you were right 
after all".  Actually, I can tell you.  It's about the same amount of times 
it's happened in the other direction.  Sometimes the best way to win an 
argument is to take a dive and give the other guy enough rope to hang 
himself with :-)