Today I read this blog entry written by a friend wo works with Ember.js: http://blog.crowdflower.com/2013/04/ember-js-at-crowdflower/
I’m not talking about Ember.js or UX or frontend. What strikes me most is this API stability thing that was mentioned. Three productive versions of Ember.js, they are about to roll out a fourth; reading these lines made my mind spinning around some API things, in unordered fashion: I remember our own experience from migrating our app to Python 2.6/2.7 from 2.4. I think of Java and the days when our product was still supposed to compile on Java 1.4 and the build stopped just because somebody checked something in that used the contains() String method (Oh yes, Java 1.4 did not have this). But I also think of how slow “standards” evolve, the moment there is a body concerned with standardizing, some kind of industry gremium, then things are usually dead (exceptions of course exist). In the perfect world scenario, stability is almost any API’s surname. But it is not the case in real life.
One might say that scripting language are especially poised for unstable APIs since they allow for such easy change. I often hear this when people try to point out to me that Java is so much enterprise and the interpreted languages are so much for script kiddies. Honestly, I disagree. It is not a virtue to let laziness dissuade you from an API change you have planned – in other words, if you have a reason to change your API, you’ll do it, it is just more work in Java than in, say, Python or Ruby.
Then there is thing about rapid innovation. Again, the moment a “standardization body” is concerned with something, things usually go at much slower pace. Having multiple versions of something is most probably a smaller problem than stifling innovation, even in an enterprise environment.
There is one big exception to this rule – the moment when multiple modules with inter-dependencies are getting unstable. You start with module x, you’ll find out that x requires y, y requires z, but the current version of z is not compatible with x. You can or could find such things in Apache Commons (which is a Java component library, not the web server product). Another proof why it is not the language that makes stability or not.
So, to summarize, if anybody thinks “oh no, so many different API versions”, I’d say, “well, for sure not optimal, but not that bad”. As long as these are isolated modules and not cross-referenced with other such modules in multiple versions, that would for sure put you in the software engineering hell…
Fun fact: If you search for API stability on the web, you’ll get tons of links. However, once again this proves the world is not just about us, the IT folks. API also stands for “active pharmaceutical ingredients”…