Sunday, September 15, 2013

How The RBS Incident Relates to Choosing Clojure for Your Startup

Couple of Hacker News/proggit articles worth combining today: "where my mouth is" and "RBS Mainframe Meltdown: A Year On".

The first article is about a long-time LISP guy who has bet his company on using Clojure. The second is about how the Royal Bank of Scotland has had a complete computing meltdown with their ancient mainframe running COBOL and is going to be spending half a billion pounds trying to fix it.

The RBS article has comments attached to it to the effect of "well, it's hard to find people who know COBOL these days" and "the people who built it are retired". It's true, right? Those COBOL guys get paid a lot of money to come in to fix these old systems.

But let's put this in the context of the we're-using-Clojure article.

The blog post mentions some Silicon Valley hive-mind discussion points like "with good programmers, language doesn't matter" and "it's hard to find people, but it's hard anyway".

But it does matter, doesn't it?

Arguably, the only reason you're getting people to do Clojure now is because either:

a) The problem you're working on is interesting, in which case the language doesn't matter at all, as the OP said.

b) The problem is not interesting, but the chance to develop in Clojure is handed to people and they want to do that.

Let's assume it's not (b). Because if it's (b), your company is screwed. The only people you've attracted are those who only ever want to use new-and-shiny and have no interest in the problem. They'll jump at the next new and shiny technology as soon as that comes along and leave you with a pile of disaster as they figured out (or didn't figure out) best practices. EA inherited one of these while I was there, an Erlang service that was acquired in that took years to remove.

So let's say it's (a) in this case. Great, you've got an interesting problem that attracts people... for now. What happens when your problem is no longer interesting?

If you put that in the context of the RBS problem, this is similar. Banking used to be interesting for programmers (I think, since there was no Snapchat back then). What happens if your problem is not interesting next year? Or in two years? Or even in 15 years? Who are you going to hire then?

Additional thing is, this RBS story is for a language that was mainstream. With Clojure, the chances are extremely poor that it will enjoy mainstream success -- Lisps have had 50 years and still haven't.

Has the OP thought about that long term prognosis? At what point would the company port away from Clojure? Or, if the company is wildly successful, are they prepared to be the only major example using it 10 years from now, like Jane Street is for OCaml?

RBS could have had that COBOL been ported to C at any time after 1972, RBS would have no problem finding folks right now. Had it been ported to C++ at any time after 1980-something... or Java after 1995... you get the idea. But apparently it never made financial sense for them to do it -- and that's a bank with big time resources.

When we're talking about a startup, at what point does it make financial sense to port your stuff off of whatever you chose initially? Sometimes, never. Whatever you choose may have to live with your company forever, as RBS and others have shown us. And that can be a huge problem if you choose to go with something that's not mainstream, maybe sooner than you think.

1 comment:

kat said...

This is an issue of choosing appropriate software early on, and your points about finding appropriate and motivated workers to run a system are relevant. but it's also an issue of having the discipline to plan and provide for the long term.

all things get old and outgrow their foundations: buildings, software, banking systems. It's easy to plant a sapling. The root system is small and the tree fits beautifully into that corner of the yard. But fifteen years on, the tree is causing major structural damage because it's too close to the house. The only options at this point are to undergo an expensive and complicated procedure of cutting down the tree and relocating it (if you even have a place large enough to put it), or cutting it down and putting in something new.

The answer is to consider exit (or transition) strategies early on. It's difficult to take the long view; it involves planning for a future you may never see, and discipline to set aside finances for a problem that is not imminent (until it is). While not entirely true, this article about the trees at Oxford demonstrates the kind of thinking that is necessary:

With regards to people running the systems, You mention the problem with people who are always chasing the new, shiny thing. However, people who prefer to stick with the devil they know are just as complicit in the failure of systems. They would rather stay working at the same company, with the same software, that they always have. They are valuable because nobody else knows the arcane, intimate details of the company's archaic systems like they do. They are difficult to replace and would have difficulty moving to a new work environment. They have a vested interest in avoiding changes to the system, lest they become obsolete and must, heaven forbid, learn something new.

Keeping a thing in good working order, be it a bridge, or a building, or a banking system, is a complicated task that requires thought and expenditures on internal infrastructure. Nobody likes it because it's hard to see direct bottom line profit from this sort of work and expense, but it's the best way to avoid calamities like the RBS meltdown.