Working on the edge

At work we worked (it’s now over) quite hard to migrate our codebase to take advantage of the latest features and bug fixes of the underlying framework and libraries (in our case Ruby on Rails). It’s hard because of the decisions that were made upfront by the consulting company who started it.

Let’s start with the background. The development started in 2008 and they picked Rails 1.2.x when Rails 2.0.x existed for almost one year already. This design decision might have been motivated by the fact that some libraries weren’t yet ported to the latest version but still. PDF-writer instead of Prawn when it was known that the later gonna become the one maintained and I can continue with other examples.

This recalls me a story of a huge homemade CMS that had to run inside an emulator for the OS running an utterly old version of Perl because they were no budget to maintain it. When you get there, it’s obviously too late.

I wanna make an analogy with the (most popular) operating system out there:

I’m using a GNU/Linux flavoured distribution (the very modular one that compiles everything) so I can update it as often as I want (usually once a day) and when something break it’s usually one of them that is easy to identify and most of the time easy to fix too.
I also use OSX at work and you can feel the upgrade fear. One medium-sized upgrade with often no possible rollback. It toke one week-end to my workmate to get his dev environment running again. During the last upgrade I had to reinstall everything coming from macports and most of the Ruby gems.
And last but not least, Microsoft Windows. How many Windows 98, 2000 are out there? Many users of IE6 are stuck to it because there are stuck to a particular version of the OS underneath too. I dunno the cost of installing a new version of Microsoft Windows into a company but it must be big (if you take into account the time required).

Web development nowadays is closer to the Linux (and some other unices) distribution philosophy than the two others. Your application is using a bunch of libraries, maybe a framework. They usually have a website, the open source ones a bug tracker, feed of the changes, mailing list and maybe hosted somewhere you can interact with (like github, bitbucket, google code, ...) You can keep an eye on the changes, update them easily.

# Ruby
gem update
# Python
yolk -U
easy_install -U xxx

I’ll not give any details about CPAN (Perl) or PEAR (PHP) since I’ve never used them.

Software development, in the web field at least because it’s what I know the most, is also subject to entropy and requires some energy to keep everything clean. Keep your working environment clean, like a cook has to clean his entire kitchen once in a while. If project manager should do regular bug triage, developer can do, for example TODO/FIXME cleanup sessions.

A trivial advice: when you start a development that will last a couple of months, go with the most recent version or why not the bleeding-edge one (often called trunk, tip, head, …) if it might be stable when you’ll be done.

I’m wondering if a company that doesn’t have the resources to maintain a piece of code shouldn’t open source it to take advantage of a community-to-build. But this has a cost too.

L’enfer des mises-à-jour, des migrations, des changements de version. Voilà ce qui m’occupe depuis quelques temps déjà. Ça ne se passe pas sans douleur, ni surprise ou questionnement. J’aimerais simplement tenter de sensibiliser à quelques choix simples pouvant être fait.

Un peu d’histoire sur le cas qui nous intéresse ici, un passage de Rails 1.2 à la dernière version 2.3, soit grosso modo 2 ans d’écart, d’améliorations, d’ajouts ou de suppressions de fonctionnalités. 2 ans qui paraissent un peu bête quand le site n’a — lui, dans sa version actuelle — qu’une année. Ce qui est peut-être expliquable en se disant que les outils annexes (telles que les bibliothèques) n’avait pas encore eux été adapté pour supporter la dernière version.

Autre exemple, plus ancien, est un CMS qui devait tourner via un émulateur car la version du système d’exploitation (BSD) n’était plus supportée. Quand ce stade là est atteint, c’est qu’il est généralement trop tard pour agir car les autres solutions ont déjà été écartées.

Pour amener l’idée finale, qui est de toujours tenter de suivre les versions récentes (ou actuelles) j’aimerais faire un parallèle avec les systèmes d’exploitation (ou distributions) :

J’utilise principalement GNU/Linux et c’est un bonheur de ce côté là puisque tout est généralement orchestré par le système de paquets (les apt, yum, portage, pacman, …). Au final, mon système est mis à jour régulièrement, quand je le souhaite et il est possible de revenir en arrière, corrigé rapidement en cas de problème.
OSX qui a un système à la Windows Update mais offre (lisez vend) régulièrement des mises à jour comprenant des changements plus importants. Bien que de tailles raisonnables elles ne sont pas toujours sans douleur et généralement sans retour en arrière (simple).
et le dernier Microsoft Windows, qui traine toujours des casseroles fonctionnant sous des versions vieilles d’une bonne décennie. Des systèmes verouillés dans le temps car une mise à jour est trop coûteuse, impossible ou jugée inutile.

Quand mettre à jour signifie réinstallation avec ou non achat de nouveau matériel, j’ai peu d’espoir que ça puisse suivre rapidement. Point prouvé avec les différentes politiques de mise à jour des navigateurs d’ailleurs.

Le développement web est assez proche d’une distribution Linux, généralement le serveur fonctionne sur cette technologie d’ailleurs. Une application va fonctionner se reposant sur un ensemble de bibliothèques, dans le meilleur des cas open source, dont il est possible de suivre les évolutions et les appliquer. La simplicité d’appliquer une petite mise à jour, au fur comparée a un gros changement est à mon sens d’une logique sans faille. La première étant satisfaisante et la seconde ressemble plus à une corvée.

Dernier petit conseil, au début d’une nouvelle application, n’hésitez pas à opter pour la version de développement, il y a fort à parier que celle-ci se stabilise d’ici à ce que vous aillez terminé. S’il y a effectivement un gain par rapport à celle dite stable.

Je me demande dans quelle mesure une application ne pouvant plus être maintenue peut y remédier en tentant d’ouvrir son code.

Yoan Blanc’s weblog

Working on the edge

About

Misc