One of the reasons why I got this job at MIT was because I was familiar with distributed workgroups. The group is spread between the USA and the UK, which requires a very different mindset if we want to achieve any reasonable speed in operativity. So, I’m the workgroup infrastructure guy here, I bought a new development box and I’m going to install all the software we need for out group to operate.

I’m obviously cloning the groupware functionalities that the ASF infrastructure is using, but I came across a problem that the ASF infrastructure still hasn’t approached because it is hardly encountered: what if you need to (and you can!) be a little bit more synchronous?

I think there are four levels of synchronicity in communication:

• asynchronous: when you can’t estimate when the person is going to be able to synch
• semi-sychronous: when your synch estimation period is in between minutes
• synchronous: when your synch estimation period is between seconds
• continous: when your synch estimation period is constant

Examples of these categories are:

• email, snail mail, fax, pigeon messaging, sms
• instant messaging, chat, shared editing
• telephone, conference calls, telegraph, smoke signals, videoconferencing
• physical presence

Another way to differentiate a technology is how many people can be part of the same communication channel effectively. The two things are not completely unrelated since the bigger the group, the more asynchronous the communication needs to be, since the synch period cannot be effectively estimated with an expensive scheduling process. This is magnified if the group is worldwide distributed and time zones or work habits get in the picture.

So, while asynchronous communication allows more people to be part of the working group, it also has the drawback that discussions tend to be less efficient in time and decision making can be a slow process.

This is not necessarely bad for some decisions as asynchronous media also tends to reduce time pressure, which increases creativity and removes the “I have to decide right now” effect and this lowers criticism and reduces defensiveness, but it is a problem when time is a critical factor and decisions don’t require deep thinking.

So, let’s say that we have a group that is small enough to allow the synch period to be much better estimated and the decision making is rather simple and doesn’t require deep long term thinking or external actions (such as labor division, synched brainstorming, pair programming, remote assistance etc…), what communication model is the best to use?

I’ve seen all four synchronous categories used to solve this problem, so let’s go thru all of them and see pro/cons of each one:

• asynchronous: email exchange could be fast (as fast as instant messaging, for example), but people tend to process email much slower than other things. They take their time. Pros are that email is already part of their tool set.
• semi-synchronous: IM is more oriented to one 2 one communication and tends to be associated with the person online presence, IRC is more group oriented and entering a virtual room is an additional action, so a person can be present online without being present on a chat group just because it forgot to enter it.
• synchronous: telephone calls have higher bandwidth, but they tend to perform poorely across language/cultural barriers. VoIP is dramatically reducing costs (which was a big problem before) but accent/language processing require much more information and also have the problem that direct voice communication is often perceived as more privacy intrusive (also because environmental noises are picked up)
• continuous: gives the highest communication bandwidth, but with the highest costs. At the current state, no technology replaces the experience of physical presence, so due to the high costs of travelling, time scheduling and such, these tend to be the highest costs.

Asynchronous and continuous communication perform poorly: both fail to be fast enough for the job (the second is also too expensive to be practical, with the current technological state).

So, the choice is between synchronous and semi-synchronous.

The most efficient and most widely available synchronous technology is telephone for one2one and conference calls for one2many. The most efficient and widely available semi-synchronous technology is instant messaging for one2one and IRC for one2many.

When I came in the group, the way the group managed itself was thru a mailing list, a weekly conference call and irregular face2face meetings. From other experience and from talking to other people, this seems to be the standard practice in corporations when they have to deal with distributed groups. And they considering a big step ahead compared to the times where there were just monthly or bimonthly meetings with one2one sporadic phone calls.

After four weeks, I find this process greatly insufficient to fulfill the communication needs of our team.

The main reason for this is that conference calls, being synchronous, perform very well for synchronizing operations that don’t require deeper and isolated thinking, but those requirement for synchronization don’t appear weekly, but appear much more frequently. Even more than daily, sometimes. A conference call is too expensive to perform on a more regular basis and moreover it is perceived as much more intrusive than another window on your desktop.

Moreover, conference calls don’t leave a transcript and speech recognition software is too poor to perform decent speech recognition when more than one person is involved and there is background noise, unless, of course, somebody is taking notes, but at that point one person cannot really participate completely (besides, taking notes it’s boring, expensive, frustrating, incomplete and partial).

After talking to the other guys, I’ve suggested that we use IM for direct private communication and IRC for more group oriented discussions. We have been using this system for the last 10 days, abolishing one weekly call out of two and this has improved things rather dramatically!

But what I really found fascinating was the concept of the IRC assistants that are implemented in the W3C IRC server that we have been using. They are bots, Zakim and RRSAgent: the first provides IRC-driven operation of the conference call machinery, driving the meeting agenda, the attendees, assigning the scriber (also known as “the victim” in this context). In short, this manages the input to the conference. The other one logs the full transcript and records actions, then generates a page in the W3C web site. This manages the output to the conference.

We don’t use Zakim because we use HP’s own cancall thing, but we do use RRSAgent, here is an example of its output.

RRSAgent is cool, but I have tons of ideas on how to improve it (for example it should send email to the person listing his/her actions, so that you have it in your inbox and keep that), so I shopped around and found PircBot, a java framework for writing IRC bots, it is soooo simple it hurts. The API is kinda weird because the guy didn’t really get the concept of inversion of control, but I think it’s really cool, it feels like writing a servlet for IRC.

But then I’m sooo spoiled by flowscript that I want to use continuations and javascript here too! so that I don’t have to recompile everytime I make a change or to have to reconnect my agent to the IRC channel everytime!!

Oh well, anyway, RRSAgent is written in Perl, so I’m writing my own to do that IRC knowledge management in Java, so that it’s much easier for me to add new features as we require them. I’ll release it when it’s usable, watch this space for updates.