Location Sensitive Posts: Do It Right, Or Don't Do It At All

When I posted that, I was at home. I live in Wandsworth (post code: SW18) in London; Camden (post code: N1) is 8 miles away according to Google Maps. To be very clear, I was nowhere near Camden at the time I posted that. (at least not as a Londoner would know it).

On my way home from work, Facebook somehow decided in a different post that I was in South Kensington (post code: SW7), even though I never crossed the river, going straight from OpenGamma HQ to Wandsworth and staying the entire time south of the river.

This is a problem.

No, You Can't Turn It Off

I'm running an iPhone 4S with iOS 5 running the most recent Facebook iOS update. Everything is as far up to date as you can possibly get.

I've tried to turn off location-sensitive Facebook updates. I've tried under Settings/Facebook. I've tried in the Facebook application. There appears to be no way that I (an otherwise relatively computer savvy individual) can figure out to turn it off.

Twitter lets you geo-encode a tweet. You can turn it on, you can turn it off. You can change your defaults and change a particular tweet (usually I tweet geo-encoded off, sometimes I turn it on for a location-sensitive post). You can take a look at where Twitter thinks you are, and if it's off, you can turn it off again. There's no such option for Facebook.

Why This Matters

In London, a distance of 8 miles is the other end of town. It's so far given our geography that it beggars the mind that if I claimed that I was at home, but some computer verified me as being in Camden, that this would not be an acceptable fudge the way that a distinction like Southwark/Lambeth, or Westminster/Kensington might be. I might as well be in Paris.

What I've noticed is that as geo-location gets better and better, people start assuming that the technology must be correct. Part of this is surely the CSI-culture that Hollywood has given us, telling us that computers are never infallible, and that all answers are on the other end of an infallible evidentiary chain. But part of this is that these days people probably do lie more than computers.

Which is why I'm so annoyed at Facebook's failures in this respect. If I tell someone (a friend; a family member; my significant other) that I'm at home watching Glee, and they see a Facebook update that says that I'm in Camden, one of the following will happen:

• They will think I'm lying and am actually at an Amy Winehouse memorial concert;
• They will think I'm probably telling the truth, but in the back of their mind think I might be lying and am shopping for Doc Martins;
• They will 100% know that I'm telling the truth, and immediately blame Facebook's bad software engineering.

Which do you think is the most likely?

Worse off, imagine that we're talking about something where there are Serious Stakes on the line: a divorce ("you claim you were home watching Glee but your phone claims you were in Camden visiting your mistress"); a criminal trial ("you claim you were home watching Glee but your phone claims you were stabbing someone to death in Camden"); a terrorist investigation ("you claim you were home watching Glee but your phone claims you were making a bomb in Camden"). As technology advances, can you even doubt one of those will happen on a regular basis? Do you think the people evaluating the technology are going to ask things like "how accurate was the GPS receiver?" or "how was the coordinate-to-placename database compiled?"

We Owe It To The Humans

As a software engineer, please let me ask for the following code of conduct to prevail:

• If you enable location-aware anything, make it obvious to turn it off, both as a default, and as a one-off action, before and after the location is determined;
• Never imply more sensitivity than your entire system (hardware, software, and databases) are capable of;
• Until and unless you have run your location system past a local in a particular region, don't enable it.

If we all follow these three maxims, we'll not repeat Facebook iOS's current failures putting me in Camden against my will.

Multi-Device Sync in iMessage

So faithful readers will know that I was a big Kik Messenger fan,, and used it to handle keeping in touch with world + dog given my nearly insane transatlantic flight schedule.

I decided, however, to give up the Android experience (keep meaning to blog about that) and use my old iPhone 3GS as my US phone, and my new (on its way) iPhone 4S as my UK phone. This, plus my iPad 2 (whose SIM I change in the plane in between London and New York), means that I can hopefully get my multi-device sync on and communicate with the vast majority of people that I SMS/IM to, who all have iOS devices.

However, I upgraded both my iPad and my iPhone to iOS 5, and iMessage wasn't synchronizing properly. Apparently this, the killer feature in iMessage (and the only one that's superior to Kik thus far in my experimentation), doesn't work out of the box. You have to change your phone settings to enable it.

1. Go to Settings > iMessage
2. Select "Receive At":
   
3. Make sure at least one Email is set (and is set on any other iOS device you have), and then choose "Caller ID":
   
   
4. Pick the email address you want to use (and make sure it's the same on all iOS devices):
   
   

And then you're in business! Shame they didn't make it default to this...

A Quick Guide to Banking Titles

With the news that the police have arrested Kweku Adoboli on suspicion of engaging in rogue trading, I've seen some confusion on Twitter as to what it means that he was a Director at UBS. Some people have implied that this is a very senior role and he was head of Delta 1 trading. Nothing could be farther from the truth.

The core issue is that Director and Managing Director have meanings here in the UK outside of financial services (someone on the board, and the managing board member), and financial services companies have redefined them here to mean different things.

In general, banking titles go as follows:

No Title

Most junior people won't have any honorific title whatsoever, they'll just have a job function ("Trader", "Software Engineer", "Operations").

Associate Director (UK), Associate Vice President (US)

The first honorific title. Usually a strong individual contributor without management duties, or a few years into the job as a Trader.

Director (UK), Vice President (US)

Someone with supervisory duties or a more senior member of a trading team. In IT, a line-level manager will usually have the title Director.

Senior Director (UK), Senior Vice President (US)

Not every bank has this step, it's just an interim step between Director and Executive Director.

Executive Director (UK), Executive Vice President (US)

Typically a manager-of-managers. This would be common for someone who's one of the most senior traders on a desk, or a divisional head in IT.

Managing Director (both UK and US)

The highest honorific you can go. Typically MDs run a desk or a division, and usually have some form of signatory authority. They almost always have budgetary authority over some aspect of their business. There are many of them.

C*O

Exactly what you'd expect. There's one of these per area (though the Group CEO may not be the same as the Divisional CEO for example).

Also, one last tidbit. CIO can mean one of two things: either Chief Information Officer, which means what it would in any other firm; or Chief Investment Officer, which is completely different. Make sure you know which one you're meeting with.

Caveats: Yes, there are firms that do things differently. No, this may not apply at your firm. This might be very heavily biased to Investment Banks. But I meet a lot of people who work in the financial services industry, and have worked there myself, and these appear to be the most generic bands and equivalency.

Good VCs Don't Charge Their Companies For Flying First

Recently I was alerted to a post by Dan Shapiro titled "How to handle a VC who flies First" through a post on Hacker News. Good article, and you should go read it.

We faced a similar situation when OpenGamma expanded in its Series B to have a multi-national presence, and multi-national board of directors. Prior to the Series B, we had three board members, all based primarily in the London area. Adding an investment from FirstMark Capital, and taking Lawrence Lenihan onto the board meant that we now had three board members in London, and one in New York City.

That meant two things:

1. We were going to start having board meetings in both London and New York City; and as a result
2. Board members were going to start to travel for these board meetings.

To make matters worse, we had two different travel policies for our two venture capital investors:

• Accel Partners, as a policy, doesn't charge travel expenses back to their portfolio companies.
• FirstMark Capital does.

The Interesting FirstMark Approach

Accel has actually been thinking about starting to charge, as many of their peer firms already do. And that's a reasonable position to take. But if and when they do, I expect that they'll follow the lead that FirstMark does in the way that they do it.

Essentially, it's in the interest of a venture capital firm to ensure that any travel that they do is necessary and in the best interests of the company. You don't want to have your partners flying all over the world all the time, or else they'll never get anything done. But at the same time, you don't want to penalize the firm for the travel that is essential to the firm.

The FirstMark approach is simple:

• Their partners don't like to fly economy (and as someone who's done 10 transatlantic round-trips this year thus far in coach, I can't blame them);
• Their partners have preferred hotels that tend to be on the pricey side;
• This is not the concern of the portfolio company.
• The partner will make his or her own travel arrangements at times and in standards of travel that are suitable for the partner;
• The firm will reimburse them an amount based on the partner travelling just for the board meeting, and in the standard flight fares (in our case, full-discount economy) and accomodation (in our case, nice, but not luxurious) for the portfolio company.

The VC wants to fly first class London to New York and stay at the Mandarin Oriental? Great, and I'm happy that he's doing well enough to afford it. But that's not what employees fly, and not where employees stay, so anything beyond what we'd consider a reasonable expense report is on him.

If the firm is doing well enough to expand their standard of travel for employees? Then they should expect to compensate their board member VC partners more as well and consider that when they decide what the standard travel policy should be.

I think this policy is fair to all concerned: business travel can be a significant cost in a business and a drain on those travelling, so it's worthy of minimization in general; but the needs of the firm have to come first over and above the luxury of the traveller.

To me, if a VC wants to charge you more than what you'd pay to fly an employee, their incentives aren't aligned with yours.

First public OpenGamma Platform release

Remember that whole thing about the OpenGamma Platform being available Open Source?

Yeah. It is..

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.