Remote teamwork anecdotes

[Alex Martelli]

Dan Sommers <me at privacy.net> wrote:
    ...
> Design meetings and similar almost have to be face to face.

Agreed.

> OTOH, once the design is set, leave me alone and let me
> simulate it or code it, and maybe even get it past the first
> round of testing and tweaking/fixing.  The last thing I want
> now is someone micro-managing and/or interrupting my every
> rinse, lather, repeat cycle.

While what *I* want, ideally, is pair programming -- somebody sitting
right at my side, alternating with me in controlling keyboard and mouse,
and in verbalizing what he or she is coding -- that's part of the huge
productivity boost I observe in a co-located team... that pair
programming works SO much better that way, that even with the best
remote cooperation tools (subethaedit onwards).

If I can't have pair programming, second-best is extremely frequent code
reviews and submits into the working branch, again facilitated by
proximity -- any question is best asked and answered f2f, often with
whiteboard &c.  Phone (VOIP or not), teleconferencing, IRC or other
chats, &c, are pale substitutes, just as you find they are at design
meeting.  Maybe another way to put it is: in test-driven development (or
its close equivalent, behavior-driven development, which I haven't tried
IRL yet but sounds interesting) a LOT of design is happening in ways
that intermix at EXTREMELY fine grain with coding and testing.  No "big
design up front", no trace of "waterfall", but rather, very iterative
and dynamic processes (including planning and estimating -- they don't
happen quite as continuously, but can't wait for "occasional" meetings
either).

Wanna talk debugging?  I think solo debugging is even worse than solo
programming -- when I just CAN'T have a debugging partner for a
sufficiently nasty bug (race conditions are the worst, but there are
many other categories vying for that title;-), I'll turn to one of my
beloved plushies (I'm firmly convinced the baby tiger is by far the most
effective debugging partner for most bugs, though Tux the Penguin has a
knack for helping spot bugs that aren't MY fault but rather the
compiler's &c -- since I've been using Python for most of my coding for
years, poor Tux hasn't seen much action recently) -- I talk out loud to
the plushy-partner to make narratives out of expected and observed
occurrences.  But a *LIVE* partner, actively checking out the coherence
of my narratives and challenging them and proposing alternatives, is 10
times more effective... the plushies don't even talk back (except in
debugging sessions that have gone on for *FAR* too long;-).

Yes, there IS a place for long solo rides -- but in my experience that's
normally one, maybe two days a week; that may vary by team, by project,
and by person (I deal with interrupts better than most people, and I'm
keener on all sorts of social interaction, bonding and networking,
_including_ small chat, than 99% of the top techies I've met and worked
with), but I doubt the effective range is any wider than 0 to 2.5
days/week.  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.

Essentially, to support "non colocated" team, you can't really have the
team meet in-person for more than about one week every month -- in my
experience, that just isn't anywhere like enough to get top productivity
(in projects conducted by agile methods -- if you're NOT using agile
methods, but either "seat of the pants" or "waterfall", you have far
worse problems to deal with than where people are located;-).


Alex