teleworking tools and methodologies (was Re: Teleowrking [Was: Anyone looking to hire a Python/C++ developer?])

[andrew at acooke.org]

Alex Martelli <aleax at aleax.it> wrote:
> As a techie, I'm anything but satisfied of what we've come up with
> in terms of techie-to-techie close cooperation, though.  Specifically,
> in my role as internal consultant/mentor/advisor, I know I've been
> hugely more effective face-to-face than via such tools as video,
> email, and so on.  None of those, in particular, seem to support
> *pair-programming* and closely related practices of design and code
> inspection -- and yet these practices are key to effective close
> cooperation and mentoring.

I wouldn't have though pair programming would have much chance of
working if you weren't in front of the same terminal.  I worked in a
very different way - effectively on mini-projects - and did sometimes
(about once every couple of months) visited "base".

> What tools and/or novel methodologies have you found effective in
> such pursuits?  "Off-line" ideas (helpful across timezone gulfs
> are fine) -- CVS or other roughly equivalent schemes, email, wiki
> and/or newsgroups -- and some widespread "online" ideas also work,
> to some extent (muds/irc/intranet-based/...).  But I keep thinking
> there must be something better -- some good ways to simulate and
> enhance sitting next to each other at a keyboard.

Being friends with the other developer(s) is probably worth its weight
in gold.  Chatting over a phone once a day is useful, even if you
don't feel you're actually working.

On a more mundane level, everyone (small company) posting once a day a
summary of what they have done is useful (a summary of what they're
going to do in the morning helps too).  This helps replace the
information you gather in "background noise" in an office.

Both those comments have a similar theme - that it's the informal flow
of information that needs help.  Requirements, Specs and Designs can
be emailed and read wherever you are, but when you're half way across
the country you don't hear someone swearing about something in your
code that could be easily changed...

Regular release cycles help too - testing and bug fixing tends to
generate some "communal spirit" and you get to poke around in each
other's code (so a distributed bug tracking database is necessary).

Andrew

-- 
http://www.acooke.org