Eduardo Pelegri-Llopart's Blog

Distance in the Internet... Time Zones and Geos

I recently attended a presentation on a study corelating the mode of interactions (face to face, phone, email) between participants with the distance between them. The study used geographic distance and reported that people geographically close to each other would use face to face communication and that they would start using phone and email as people got farther away . This may be correct for the community used in that study but the results do not match my experience: we use email much more often than that and I believe geographic distance is not a good way to measure distance in the internet.

I interact with many people, some have offices in my building but others are located in other sites in the West Coast (of the USA) and elsewhere in the world. Most of my interactions with other software engineers are through email, regardless where the recipient is.

Email is the prefered medium for our engineering community. Email is asynchronous, fast, and can be scanned quickly. We complement email with (synchronous) meetings where people are seated around a virtual room, some face-to-face, some teleconfering using phone, video and VNC. Some groups also use IM and chat rooms.

My experience is that geographic distance is much less important than time-zone distance. When the time-zone distance is small, email and even teleconfs hide any geographic distance. You can engage in a sequence of email messages and solve a problem. Or you can arrange for a virtual meeting and do high-bandwidth exchanges. Sure, there are some problems with virtual meetings and one needs to pay attention to the non-local participants, but the problem is manageable.

Start increasing the time-zone distance and communication becomes more complicated: the number of mail exchanges in a day are reduced; there are fewer overlapping hours in the work day. Increase the time-zone distance, or include multiple sites (say India, USA and Europe) in the conversations and email exchanges slow to one a day, and meetings just can't happen.

So, what works for collaboration over large time-zone distances?

Here are some ideas that we have used:

• Design out the problem: rearrange the tasks so that where fast turnaround is required the time-zone distance is low.
• Complement with additional interaction mechanisms: I've found web sites, Wiki and bulletin boards to be less susceptible to time zones as they are more static and capture snapshots of exchanges. These mechanisms are not a complete solution; if you have suggestions and/or expererience, please share it.
• Kick-start the relationship. The effect of time-zone distance makes it specially hard to "figure out" the other party so one can translate idioms (typed or vocal) into their intended meaning. One trick that we have used is to ask for a picture and for some short biographical blurb of the other party and then we post this in an internal site. Then it may be easier to add other bits of information to that core to "figure out" the party. Another, more traditional mechanism in the business world, is to fly some people across the time zone.

Bookmark blog post: del.icio.us Digg DZone Furl Reddit


Comments

Comments are listed in date ascending order (oldest first) | Post Comment



• Communication still the bottleneck
  The Mythical Man-Month, Peopleware, and other more research oriented studies have shown over and over, the dominating factor in any medium to large size project is communication.

  
  When you've got groups separated by large time-zone differences, the communication flow slows to a trickle. Most of it is simply lack of simultaneous work hours, but part of it is out of sight, out of mind. If you've got a question you tend to ask your buddy in the cube across from you before seeking out a remote expert who may or may not be around.

  I think partitioning is part of it, so you have two groups working on separate items that don't require a lot of interaction. This requires stronger up front design and requirements so you don't have constant back-and-forth to resolve questions. In a nutshell, widely separated groups don't fit well into the "design-on-the-fly" XP culture. Maybe you could run each subproject that way, but you've got to do the big partitioning up front in a way that's unlikely to change.

  Personally, I think if you're going to develop with remote groups you just have to assume a larger productivity hit than if they were local. You'll probably also have to have substationally more process than you're used to in order to avoid gigantic effeciency penalties lots of remote communication would involve. Factor that in on your ROI when you figure out how to staff the project.

  Posted by: ckessel on August 25, 2003 at 11:34 AM

• How to get up to speed quickly.
  One of the challenges to overcome in dispersed teams is how to get individuals that is new to a project to understand an implementation of a technology quickly. The IEEE has a standard notation for circuit diagrams. Every electronically minded person with the appropriate training can figure out what happens by looking at a diagram, whether that person is from Plymouth, Perth, Port Maernog, Pretoria, Pasadena, Phnom Pen or Prague.

  To embrace a similar notion in the documentation of technologies, i.e. use UML or something similar. Another issue that sometimes makes it hard for new participants in a project is to figure out why a technology is implemented in a certian way.

  So, a diagram showing the interaction of software components/classes/pieces/parts, together with a description of how it works and a short motivation for the design rationale is invaluable for people that cannot "just drop in" to figure out how stuff works.

  Posted by: axlm on September 17, 2003 at 03:06 AM





This work is licensed under a Creative Commons License.



Powered by
Movable Type 3.01D