Eduardo,
I thought you are in holidays, is the weather so bad that you prefere
discussions with me? ;-)
> Two large concentrations of GF developers are in the West Coast of the
> US and in India. Asynchronous mail-based coordination between those
> two
> sites is very hard. A common symptom is the "nothing happens while
I'm
> awake; I went to sleep and whole conversations started, flamed and
> ended". Or the "two-email exchanges, 10hrs pause, two email
> exchanges...".
This is just a symptom of an architectural design of the overall system.
If the line has a long delay (like internet to the moon), the solution
is to put more power in the nodes and reduce the communication
roundtrips by increasing the semantic information per package. Isn't it
what we all tell our students? :-)
What I like to say is: If you split the system into small bricks, an
have one elected chief for each brick, then there shouldn't be a need
for speedy discussions. If you want to change the brick, develop a
patch, send it to the chief, and wait for his detailed answer. No need
for lots of emails going back and forth. The patch will be containing
work for several days, and the answer will contain details that last for
several days.
Heavy discussions with lots of small emails going back and forth is the
symptom of a hierarchical system where lots of idiots work for a
stressed manager. This is NOT what the community shall be like. If the
chief and the contributor both know their area of work very well (what
is given if the brick is small enough) then they do not need to send
lots of emails.
At least this is my experience with both company architectures. We tried
both of them and recognized that it makes no sense to have masses of
unexperienced hackers far away and try to manage them centrally.
Instead, have few highly experienced architects working in a losely
coupled way. The communicate less mails, but more facts per email.
For example, in our company, we just exchange information about once a
week by email. Each engineer can work when and where he wants, since he
knows his brick so well. I just have to publish a tasks lists and people
pick their jobs. No need for more communication or daily scrum meetings
etc. It's just about knowledge and responsibility. Not about time zones
and reply delays.
Regards
Markus