One of the projects I admire most is KDE. What millions of dollars and several highly disciplined companies could not accomplish, a bunch of German developers managed to do. They did not have the big budgets, marketing divisions, and even technical wizards (The only technical wizards I know are the ones who grok lisp).

So, what do they have?

In word, right culture.

They built a very good developer culture. it positively invites you to develop and contribute to the project. Where else do you find housewives contributing to projects? Or, professional cooks contributing to the projects?

While there are several positive things they developed (all from engineering point of view), I would like to point out one thing we can copy from them. It is the communicating culture they developed.

I know more about the projects in KDE (take for example http://www.kdevelop.org) than any project that I am currently involved in now. For example, I know who all are working in that project. Which tools they use. I can even do a build!

So, how do they do that? Here is my take on the growth of that culture:

1. Set up infrastructure for communications

   These people have mailing lists from the beginning. Almost all the conversations are carried out. If any person is contemplating a design choice, it is discussed there. In fact, the emails force a certain level of discipline that cannot happen in a closely located group. For example, over the email people have to be precise. They have to explain details. As opposed to discussions, the emails are available for posterity.

   Do we have the right infrastructure in our company? Yes, we do:

   • We have mailing lists.
   • We have newsgroups. For any informal discussion, we can carry on there.
   • We have blogs, where elaborate notes like these can be posted.

   So, we have OK with respect to the infrastructure. 10 per 10 to the IT team!

2. Use email as an interactive medium

   The KDE teams discuss issues over the email. They do not come to decisions and use email as a repository to hold the meeting minutes. What it means is that we can see the genesis of ideas. We can see why decisions have been taken. If somebody comes in and says "why don't we extend XEmacs to do KDE programming" the Kdevelop guys can say "look at so and so posts" where that issue is discussed.

   Let us compare to our mailing lists. Here, we fail abysmally. Personally, I am glad to say that I use email as a discussion medium. Lot of junior members are unfamiliar with such concepts. Several members of the management (including senior management) fails in leading the company by example. How do they fail?

   • They do not send mails to mailing lists; instead they send directly to people. What it means is that they are valuing secrecy over openness. History has shown that is not a great idea.
   • They prefer phone calls over emails. Not to just mention that phone calls are more expensive than emails, phone calls are not always the right communication choice. For example, you don't call your friend and give URL over phone, do you? Also, phone calls are one-to-one and ephemeral -- there is no record of such activity and you cannot recollect with clarity.

     Could it be that they do not wish to be accountable for their words -- hence they prefer to communicate over ephemeral medium? More likely explanation is that they are just lazy. Or Luddites.

   • They are excessively formal. That is, communication is expensive to them. They respond after deliberation, robbing of spontaneity in the emails. They talk in non-sequitars. They are non-committal. They are verbose. They are circumspect.

     In short it is as much fun as reading a letter from the lawyer.

     What it means is that it raises the barriers for communication. People are intimidated to communicate quickly and informally. Perhaps they will have to consult their lawyers first ;-).

   • They do not respond immediately. That is, they take their time in communicating back. What it means is that emails are robbed off as a mechanism of discussion. It is no longer a place for dialectics.

     If you think about it, you must have been taught in kindergarten. If somebody talks to you, do you not answer them? Even if you are busy? Why not extend the same common courtesy towards the person who is not fortunate enough to be sitting next to you and has to resort to using email?

   Whatever may be the reasons, if you find that your manager or a co-worker is not communicating well over the email, please send polite mails sending a link to this article. Example could be: "Hi: Did you read this article by Rama? Here is the link". Please Bcc me when you do that. Of course, if you are a manager, make sure that everybody in the team reads this article.

3. Resolve differences over email

   Lot of times, people disagree. But the strength of KDE is to carry on discussions and recognize when the dialog is not being fruitful and proceed without the issue being resolved.

   How do we rate on that one? Perhaps we don't even have disagreements over emails, so this question is moot in our case.

4. Communication as a part of a process

   In KDE, for example, the only way releases are made is over mailing lists. Only way the work breakup happens is over email. It means that the process of release incorporates the mechanism of open communication.

   How do we rate on that in our company? Not too well, I am afraid. We may make final announcements and releases over the email. But, we do not discuss the release plans over email. We certainly do not discuss requirements etc over emails.

5. Low cost of reading communication

   KDE is not always good at this. But, lot of people in there are good at this. For example, they quote appropriately and reply appropriately. They do not send large attachments, preferring to use standard mechanisms, such as CVS, for collaborative editing.

   How are we doing in this? Poorly. In stead of replying to emails, we consolidate in word docs and send attachments. Imagine the extra few clicks to open the doc and reading it. Also, imagine losing the thread of communication.

So, what does all this communications mean? It will help reduce the ramp-up time, increase the transparency, and let us learn from one another more effectively. In the end, you benefit, the customer benefits and the company benefits.

I guess, I went on a bit more than intended. I hope to write more about KDE and its engineering marvels later on.

Couple of clarifications are in order:

1. When I suggested email as dispute resolution -- I meant in the technical arena. The advantage of discussing technical merits over email is that the merits alone decide the choice and the posterity has the benifit of seeing the discussion.
2. I agree that sometimes it is so much easy to just talk across the cubicle and get the answer you want. Nothing wrong with that. Except that sometimes, relying on it excessively shows that you may be ignoring the fundamental problem of unclear assumptions or expectations.
3. In addition, extreme programming kind of philosophies posit that working next to each other and making quick decisions has lot of advantages. No doubt. However, when the intenals of the system are required to understand the working of the system, it is important to share that information in a public communication channels.