Suppose someone told you that there was a new revolutionary vehicle that looked and acted like a car, but it could also fly and sail. To make things simple, let’s just ignore the technology that would make this possible. How would you actually drive such a thing? For example, what would the brakes (pedal-brake or hand-brake) do when you are in the air or in the sea? In a (terrestrial) car, it’s supposed to stop it, but in the water even if you anchored the “vehicle”, it will still move along the waves. In the air…well it just can’t be stopped. It’s the law of physics. Also, you can’t event turn off the engine while you are in the air, as opposed to land and sea. Even if some clever engineers devised a way to fit into a single vehicle the engine of a car, a boat and a plane they would also have to include three quite different interfaces for each kind of driving. And you would have to learn the three kinds of driving, because the rules of driving planes are way different than the rules of driving cars.
The above story may state the obvious but for us, software engineers, it is (sadly) not that obvious. Since the dawn of computation, we are always trying to pack different little things into one common meta-thing that will make irrelevant which little thing you are indeed using. In fact, these abstractions are the fabric of most modern software applications: we have abstractions for databases so that we don’t have to mix SQL with our programming language, we have abstractions for xml parsers, so that we can easily switch the underlying engine, same for logging, and so on.
The canonical example is trying to abstract away the communication channel. On object oriented communication protocols (e.g. CORBA, RMI), there’s this myth that you can interact with an object independently of its location – you always treat the object as local. This has proven many times to be flawed – if the connection with the remote server drops or takes too long, the “local object” metaphor starts to break. Also, the idea of building a protocol that can run seamlessly on top of HTTP and SMTP is just that. An idea. Or an academic paper. In the real world, you don’t try to create a synchronous protocol over an asynchronous channel.
This leads me to the new Facebook messages, that will unify into a single seamless interface four communications channels: e-mail, SMS, IM and Facebook messages. From the official announcement:
Today I’m excited to announce the next evolution of Messages. You decide how you want to talk to your friends: via SMS, chat, email or Messages. They will receive your message through whatever medium or device is convenient for them, and you can both have a conversation in real time. You shouldn’t have to remember who prefers IM over email or worry about which technology to use. Simply choose their name and type a message.
Oh man, the “let’s hide that pesky communication channel” virus that plagued the programmers’ lives for so many years is being now transported to the end users. You see, when you try to combine different dimensions, you have no choice but finding the few features that are common among all dimensions, and leave out the rest. Guess what? The users won’t be happy. Consider the typical features (and behavior) of IM as compared to e-mail? When you write a message to someone using IM, you expect to see a response in a matter of seconds. On the other hand, when you use e-mail, you tolerate a much bigger delay – a few hours lag is common in e-mail exchange. And let’s not forget the size of the message. It would be absurd to chop into dozens of SMS a long multiple pages messages that was originally meant to be sent through e-mail. But I guess it’s an interesting geeky challenge, and that’s why it has been tried over and over. And since Facebook is probably dominated by geeks, they couldn’t refrain themselves of giving it a shot.