Most information here is in English. Only entries not relevant for the international audience are in Dutch.

E-mail is often the least effective means of communication. Use the phone of you want a cheap and fast answer for your questions.

Guy Kawasaki has a nice weblog for entrepreneurs and start-ups. Absolutely worth reading. I like the term I found in today's entry: FUQ for a fabricated unanswerable question.

E-mail lends itself to very open ended questions where the burden of solving the problem is completely shifted to the recipient of the mail. Every now and then people ask me things in a one-sentence mail that took them less than 10 seconds to write. Something like: 'Help, my printer is not working'. Sure, I could solve that problem, but with the question being so unspecific, I will have to narrow down the problem first. In my reply, I first have to ask a few questions. In the example: what are the make and version of printer, computer, operating system, software, etc. Even asking all those simple questions will take me several minutes. Then nothing is solved yet. All this for information that the asker could have provided immediately in the first mail, if he were not so lazy.

If one is lucky the problem can be solved in the next round when the asker has answered all my initial questions. Sometimes the number of initial questions I have to ask is so large, that it would take half an hour of my time to write them down. That is too costly, so I just write the must important ones in my first answer. It will then take additional mails going back and forth before the problem is finally solved.

This type of mail communication wastes my time and, in the end, of the original asker as well.

Mail has the name of being a very effective means of communication. Well, more often than not, it is a big time waster. I am not thinking about the obvious time sinks such as spam, co-worker spam, cover-my-arse carbon copies, and daily joke of the work place. These are productivity killers and most of us understand that, except the punk in accounting who is sending the daily joke (40 Mb video, of course) and the arse-covering project lead who CCs all managers above him in the hierarchy (but no one below him, of course, imagine that in future subordinates could confront him with his writings).
People honestly believe that mail is effective. They think so because it is much faster than snail mail and, unlike the telephone, is a asynchrous medium where the receiver does not have to be available at the same time as the sender. You write a simple mail and get the immediately gratifying feeling that you have done your task and that your problem is now on someone else's to-do list. But now let us make an honest analysis of what is going on: you have dumped your problem on someone else's plate with a too short an e-mail, because typing is not your hobby. Since the expert that you are asking is therefore forced to ask further questions, the correspondence goes back and forth several times. The total lead time is miserable, because every message going back and forth can only be answered when the recipient is in and has time to check his mail box. From the point of view of your organisation you have wasted every one's time.

Compare this with the telephone. Granted, it may take some time before you can reach somebody, but once you get to that person, the problem can normally be solved in a few minutes. The phone is a highly interactive medium where questions and answers can follow each other in rapid succession. I even do not mind if the initial question in a phone conversation is too broad. I too can talk faster than type e-mail, so I am glad to ask a clarifying question. Just one. In an e-mail I would ask a few of those questions in my first reply to keep down the lead time. However, as the phone is so interactive, single questions do not add to the lead time.

So if you have a question that cannot be answered in less than ten words: take the phone. It saves my costly time and you will have the answer earlier.

I am not suggesting that e-mail is completely useless, only mildly so. Sometimes, people cannot be reached by phone at all, sometimes the expected answer is short and requires no particular hurry, sometimes a document is the basis of the conversation, sometimes people live in a different time zones so finding a suitable time to make a phone call is a problem, etc. The art of effective communication is knowing when the use e-mail, phone or a combination of both. There are several powerful patterns of combined use of e-mail and phone:

• e-mail the document and discuss it over the phone
• if you do not succeed in getting phone contact: use e-mail to ask the other to call back and tell when such a call-back would be convenient; then discuss over the phone
• discuss over the phone and confirm the agreements in an e-mail
• clarify the question over the phone and one of the parties prepares the answer and sends that via e-mail

Do not F.U.Q. me! Use the phone.

 2006.02.03
MeWare, YouWare, UsWare, ThemWare

Eric Sink wrote an article why he replaced CityDesk with something homebrewn. In the article he introduces the terms MeWare, UsWare and ThemWare for software that is used only by the developers, by developers and customers and just by customers, in that order.

I would also add YouWare: software for others, but contrary to ThemWare, for a known customer who can be asked for clarification of the specifications, or who will interfere with the development process in the form as an endless creep source. In other words contracting.

At Garabit make a lot of MeWare, by the way.

I am glad to say that I am very a very happy CityDesk user.

 2006.02.01
Jeremy tries to destroy a Toyota

In this 16 minutes video, Jeremy Clarkson of Top Gear tries to destroy a Toyota pick-up truck with some hefty equipment...

 2006.01.26
Recursion

In Joel on Software people argued about the pros and cons of recursion. Although some interesting objections were brought forward, I am again astonished by the shortness of the intellectual horizon of many practitioners in our discipline. I contributed:

How do you keep your data in an iterative design? You put it in objects on the heap. No matter how you put it, you have just invented the stack as an abstract data type. This should be a bad thing, because you are reinventing the wheel. However, often your heap is larger than the available stack space.

If that is the case, that is a clear indication of another problem: wrong programming language for this recursive idiom. There are plenty of languages that do not have this limitation: some of them put the activation records on the heap (some implementations of Lisp and Small-talk) or they allow tail recursion. Ideally, you have both.

Many posters made valid remarks about the limitations of recursion, but they forgot to mention that this is not a limitation of recursion per se, but of the tool they use.

 2006.01.17
IDDMVDBVMESPO, DLS

All my blogs: