Live By The Platform, Die By The Platform

As a software developer the biggest risk I can take is developing on someone else’s platform. The irony, of course, is that, as a software developer, that is pretty much all I do.

Let me explain: when I write applications for an operating system I am writing on someone else’s platform. I have no control over that underlying platform. If that platform breaks my code, too bad. If that platform dies on me, tough luck. If that platform changes the rules of engagement, so sad.

Often times, as developers, we rely on two platforms or more. Say, for instance, I write an app for Android. Not only am I beholden to every change made by Android but I am also beholden to every change made by every licensee of the Android operating system. Now, let’s compound that problem. Let’s say I require login authentication using Facebook. Oy! Add fuel to the fire. Any changes made to any of those could have a profound impact on my product or service.

I wrote apps for Palm OS, made a good living at it , too, and was highly influential in that space. Does anyone care now? No. I might have been developing for VAX systems. I lived by the Palm OS… and died by the Palm OS.

Look, folks. I know we are all upset about what is happening to Twitter (info here, here and here) but the reality is that developing on top of it has been a questionable decision for a long time now.

The web is open, right? With my own server I’m in control, right? Even the web provides no safety. I do most of Infinity Softworks’ web work in Ruby on Rails. When David Heinemeier HanssonĀ and the crew developing Rails decide to make a change, I’m pretty much stuck. Yes, at least there I can make decisions about when to upgrade to the latest version [1]. All the same, though, it isn’t really feasible for me to run Rails 1 forever. Not only does underlying support and my ability to advance and improve my own software end but I also never take advantage of fixes (like those for stopping SQL injection, one of the more significant problems for any database-based web app).

Don’t buy into that argument and think the web is safe? You’d still be wrong. Even if I can control my own destiny on the server, I still can’t in the browser. As if it would be the first time that Microsoft broke Internet Explorer and left me scrambling at the last minute to make something look right.

The problem is very easy to compound. I’ve been developing Rails apps longer than Objective-C [2]. There is a new framework called RubyMotion that lets me write apps for iOS in Rails and then the framework recompiles it into Objective-C. But iOS 6 launches in a month and how likely is it that RubyMotion can keep up? Will it be able to support all the new software and hardware changes? And if the platform doesn’t take off or the developers lose interest then the problem is even worse. By choosing that intermediate layer, I’ve made a profound business decision that could haunt me horribly in the future.

Even within Objective-C there are various off-the-shelf frameworks (such as frameworks for parsing and creating JSON files used to pass data between an app and a website) that help me write code faster. Choosing one that I rely on, one that isn’t being updated for major new revs of the OS, is an extremely dangerous proposal. If I’m going to pick one, I damn sure better be certain that either 1) I can update and change the code myself; or 2) I can swap it out for a different framework.

Now, let’s get real. Unless I am going to write the operating system and develop all the hardware and figure out my own programming language, it is inevitable that I will write software for a platform. The trick is to minimize the risk.

  1. Choose platforms that will likely be around long-term
  2. Pick platforms that give me some level of control
  3. Decide to work with stable companies
  4. Minimize the number of intermediate layers

We don’t have a choice. As developers we rely on platforms. Let’s be smart about picking the right ones.

[1] Assuming I am running my own servers and have control over such things.
[2] Although I code more in Objective-C and am much better at it.