Kik Messenger: One Feature Pack Away From Perfection

I've found that I'm now splitting my time quite a bit between London (where I live) and New York City (where OpenGamma's second investor lives, and where we're opening an office). As such, I've started facing some of the major issues faced by modern, fully-connected individuals dealing with multiple countries on a regular basis.

In Which Americans Fear International Dialing

So let's start with one very simple fact: Americans, as a whole, have a dramatic aversion to ever, under any circumstances, dialing a foreign phone number. Partially this is because they can call the entire United States, as well as Canada, without having to ever learn how to dial properly internationally. Partially this is a reflection that every US carrier (landline or mobile) will shaft you if you dare to dial a foreign phone number without planning very far in advance. Partially this is because except for a few key, international industries and roles within those industries, Americans just don't have to do this on a regular basis. It doesn't matter. What does matter is that for a massively large cross-section of USAmerica, international phone numbers may as well simply not exist.

Europeans are far more used to dialing internationally: we have to. If you had to dial internationally to dial someone living in the next state, you'd get more used to it. If I try to give out a British phone number to a French restaurant to reserve a table, I just say "country code 44" or if typing, "+44" and they know what to do. In America, you start with "country code" and before you know it, someone's asking you if you have a US phone number. If you don't, they just don't bother.

So if you spend much time in the US, you need a US phone number. Which I now have.

In Which Mobile Carriers Shaft You

So let's consider all the ways in which mobile carriers will shaft you, the well meaning international traveller:

• You'd like to place a call from your phone, physically located abroad, to your home country? That'd be an extortionate charge, thank you very much.
• You'd like to place a call from your phone, physically located abroad, to somewhere next door to where you're physically located? That'd be an extortionate charge, thank you very much.
• You'd like to receive a call on your phone while physically located abroad? That'd be an extortionate charge, thank you very much.
• You'd like to do something as daft as call a third-party country while abroad? That'd be at least double the extortionate charges as the ones before.
• You'd like to turn on data roaming and actually consume mobile data? Hold on to your wallet; you'd be shocked and horrified at just how much that's going to cost you. In fact, don't bother. For the price of a one-week trip, you can buy a throwaway smartphone and SIM if you're willing to use a second device.

For all those reasons, when I set out to get a US phone number, I made sure that it was on a smartphone (Android; separate blog post to come on a long-standing iPhone partisan learning his way around Android). This way I should, in theory, cover all my bases: iPhone + UK home number when in the UK (and phone/SMS roaming in case someone should call me from home); Android + US phone number when in the US (and phone/SMS roaming in case someone should call me from the US).

There was just one problem: trying to corral all my SMS conversations.

Enter Kik

Those of you on O2's shockingly horrifically bad (think: you have to get over the thought that your SMS messages will reach their destination in less than a few days, if at all) SMS service will feel me when I say that SMS rocks, but O2's provision of it is virtually unusable.

Given the amount of time that I spend abroad, and given how bad SMS is for O2 iPhone users here in London, I thought I'd give Kik a try.

Kik's a great service, in that it's Just Like SMS, with a few key advantages:

• It's instant. I've sent Kik messages between two devices next to each other, and they're very often delivered within the 100ms that defines human reaction time.
• You can see when they've been handed off to the recipient device, and when they've been read.
• It uses your data allocation rather than SMS allocation, which in this world of millions of free messages a month isn't that useful, but when you're abroad and SMS-ing people all over the world, it matters.

Basically, the best way to explain it is that Kik is Blackberry Messenger for any smartphone device, which is why RIM kicked it off the Blackberry.

So I got excited, and convinced the majority of the people that I text the most to get Kik.

Aside: The Dataficiation of Primary Phone Functionality

One of the most interesting things that I find about Kik and Skype and all manner of other services coming to smartphones is the conversion of functionality that used to be specific and dedicated to the phone networks to pure data-only plays. Phone calls? Skype/VOIP over your data connection. SMS? Kik. MMS? Facebook photo upload. Video calling? Facetime/Skype. All these things that mobile carriers built very specific functionality for in their networks are being very quickly replaced by equivalent (but superior) functionality delivered over the data pipe. I reckon it won't be very long before the first iPhone/Android phone (or carrier plan) that only works with data, and doesn't have dedicated logic for phone calls and the like.

Kik Shows Its Limitations

So I'm prepared. I've got my iPhone for the UK, I've got my Galaxy S for the US, I've got a bunch of people on Kik, I'm ready to go.

And then I actually try to use it in the manner I was intending. It doesn't work as I thought it would. D'oh!

Kik only supports a one-device-per-account model. Log in using your Android phone? It now gets all messages, and your iPhone gets none. And it only gets new messages. History? Nope.

Log back in on your iPhone? Your Android phone gets logged off, and you lose all the old messages you already had on your iPhone.

This is not what I had in mind, and as a result (it took me a while to actually figure this out) I just went back to SMS on my most recent trip to the states. At least then I've got history (though of course it's not across devices).

The Ultimate Feature Enhancement

So let's get to the meat of this long-winded tale. What would make Kik really solve my instant-IM-on-a-phone conundrum? Better support for multiple devices.

What does that mean in practice?

• I can log in from multiple devices simultaneously
• When I log in from a new device, full history of conversations is downloaded
• When a new message comes in, it's delivered to all logged-in devices (and the message has been read notification follows the first one on which I read it)
• When I send a message on one device, the sent message gets delivered to all other devices.

Here's the thing: I'm actually willing to pay (and pretty handsomely) for an enhanced version of the application/service that does this. You want to make it a paid-for enhancement? 100% fine by me. Just say the word.

So Kik team, ball's in your court. Great service, 90% of what I want, highly recommended in general if you live on one device, just that last bit needed to satisfy the multi-device, multi-national crowd.

Postscript

Turns out this problem has left many people I introduced to Kik leaving the platform. I raised it on the official Kik GetSatisfaction page. Let's see if they respond.

OpenGamma Series B Link Roundup

In case you've not been glued to Twitter, you might have missed out on the news that OpenGamma completed its second round (e.g. Series B) of funding late last month.

Just wanted to provide a quick link roundup of some of the more interesting news on t'interwebs relating to the financing. As meaningful stuff comes up, I'll keep this updated over the next few days.

• TechCrunch Coverage.
• VentureBeat Coverage.
  • my response to the misunderstandings in that piece on the OpenGamma Blog.
• The joint press release between OpenGamma and FirstMark Capital
• Lawrence Lenihan's perspective on why FirstMark Capital invested in OpenGamma.
• My personal thoughts on the financing

Scala Considered Harmful For Large Projects?

Original Tweet

Last week, I was having an extended email conversation with Geir Magnusson Jr. (yep, that Geir, of Gilt Groupe/MongoDB/Apache Software Foundation fame), where we were talking about whether it was a good, bad, or indifferent idea to allow people to start to include Scala into large-scale programming projects that were otherwise based in Java. Geir and I ended up both agreeing that this was actually a bad thing, and should be avoided for the time being.

I tweeted the above missive, and all of a sudden I had more than 10 people contact me saying "please tell me more!" Let no one think I ignore my faithful readers.

What do I mean by a large-scale programming project? I mean one with the following characteristics:

• It has a sufficient size that not every developer is potentially even familiar with every module.
• It has distribution such that in a production use case, it is not a single monolithic process/binary.
• It has enough people working on it that there is some type of specialization in terms of the teams and/or programmers.
• It has flux in the developers (new people joining, people being replaced).
• The same code base has been in constant development for a period of years, or is anticipated to be.

I've written about this in the past, where I referred to my desire for a Journeyman Programming Language. For what it's worth, I'm 100% behind the Backwards Incompatible Java movement spearheaded by one of OpenGamma's developers, Stephen Colebourne. And in that frame, what we're talking about in a large-scale programming project is precisely the context in which a journeyman programming language becomes useful.

So why did Geir and I concur that someone who has a large-scale Java programming project shouldn't start adding Scala into the mix?

Two main reasons:

• The inherent problems in a split-language project;
• The sheer flexbility (by design) of the language;

Do You Really Want Two Programming Languages?

Let's say you've got a single programming language in your large-scale project. In that case, you hire people who know that language; all your tooling is specific to that language; you try to make the best use possible of that language.

Any sufficiently complex large-scale programming project will likely have multiple programming languages inherently (usually because you need to use a particular programming language for a particular function or to integrate with someone else's code). But should you try to intermingle them by design?

Once you've done that, you've started to add unnecessary complexity to the project:

• Do you have to start hiring dual-language programmers, or spend time training them in the language they don't already know?
• How well does the tool chain integrate? Are there key gaps or differences in operation?
• Are you going to inadvertently split the team into people who are comfortable with New Language versus people who aren't? Is that going to reduce your staffing flexibility to assign tasks to developers?
• Is there going to be an impedance mismatch in terms of people or technology in crossing the language boundary? Is that going to cost you?

These are questions that have been faced by programming teams for years, and usually people come down on the side of not allowing programming language proliferation, unless it's part of an effort to upgrade/migrate the whole code base over time from an obsolete language/model to a more modern one. Would you really get that much benefit from Scala to include it at this stage? I doubt it.

Modern Java has a lot of the stuff that's in Scala. It's not as well integrated, much of it is bolted on as an afterthought, and quite a bit of it is based on convention, but you can get a lot of good stuff out of Java written in a very modern style. On balance, I don't think you get that much out of Scala to warrant its introduction into an existing large programming project.

Language Flexibility Bad For Large-Scale Projects

Let's assume that you're working in a programming language like Scala or C++ that lends itself by design to what I would consider to be abuse of the programming facilities (whether it's the ability to write BASIC code inline in the language, the ability to introduce APL-like operator character insanity, or the gratuitous abuse of the compiler that is turing-complete lambda calculus in the templating system). These are, I 100% concur, cool features. It's very very cool to see someone doing something like the BASIC DSL.

The problem is that if you have a language designed to make it easy to do this, you encourage people to do it. And that's when problems start.

Large-scale programming projects need to avoid this type of thing at all costs. In my opinion, there are several key requirements for the codebase for a large-scale programming project:

• The code must be intuitive and fast to comprehend for a developer familiar with the rest of the project, but not the code in any particular module. In other words, anyone on the team can edit/fix/enhance any other part of code (where they understand the business concepts and/or underlying math).
• The code must be intuitive and fast to comprehend at any point in the future. In other words, you can't have serious issues looking at old code (that's still in the code base) or old edits (where you're trying to figure out why a change was made by looking at history).

Does an inherently flexible language with kewl DSLs and custom characters and template abuse satisfy these? No. It doesn't satisfy the temporal understanding clause (because a DSL that doesn't get consistently used over time loses understanding), nor does it satisfy the pan-developer clause (because not everybody on the team, even if they know Scala as well as Java, may know the DSL or be able to effectively type in high-order Unicode glyphs).

Ultimately, a programming language that's useful for large-scale programming projects needs to have clear, unambiguous grammar and syntax so that any developer familiar with the project and the language can instantly figure out what's going on. Any features (operator overloading, terse/different method invocation syntax, DSLs) that add time in trying to figure out what a block of code does slow down the project. Sadly, Scala is chock-full of them, and it appears to be considered good Scala style to use as many of them as possible.

Can Scala Work?

Although you may think I'm all about hatin' on Scala, the answer is actually Yes.

Neither Geir nor I consider Scala inherently harmful to a large-scale programming project. It can be a very good addition, if your tool chain supports it and you're willing to train staff so that everybody can handle it.

But you have to have even more rigorous coding standards and review process to make sure that the features of the language that excite the "insanely cool programming techniques" crowd don't get used. You have to do what every C++ programming group has done for years: pick the features of the language and library ecosystem you're going to use, use them in a consistent way, and never ever deviate.

Note that I actually think that if you're kicking off a new project, you owe it to yourself to take a serious look at Scala as a programming language base for that project. But if you already have a large-scale Java-based programming project, I personally think that I would avoid it as much as possible.

By the way, lest you think that a new component or module comprise a new project in my thoughts, you're sadly wrong. A "new project" is one where, in my opinion, the entire technology team is separate from the previous one. In other words, a new codebase altogether. Think: new startup; new Line-of-Business funded application; heads of technology reporting into different parts of an organization.