Us developers, code monkeys, or call us whatever you will, get a really bad press on occasion. Managers, who don’t understand what we do or why we do it; customers, who think we never do what we’re asked to do; the media, when some of us slip up in slightly more unfortunate and public ways. It’s not always a fun job.

We often try to temper this by consoling ourselves with having fun with the latest technologies, languages and modules, and delivering “cool” solutions which do what needs to be done in the best and shiniest way. A fair dose of this you can get away with — and particularly more so in academia than in business. In my last job — in academia –  we were quite some way ahead of the commercial curve with a few of the things we were trying to do and the methods we chose to achieve them. In my current job — working in the financial industry — we’re still ahead of the commercial (well, common-off-the-shelf) curve, but there’s understandably more importance on writing code which is supportable, rather than just plain cool.

Pragmatically, this means that sometimes, even though there might well be a best tool for the job which has come onto the scene relatively recently, it’s not always the right tool for the job.

I’m going to choose an example I’m very familiar with: Perl. Yes, I can already see some of you recoiling in horror. I code Perl for a living. I write thousands of lines of Perl with a song in my heart and a $_ on my fingertips.

One thing Perl does really, really badly is object-oriented programming. If you thought C++ was bad from an OO perspective, Perl will send you running, screaming, for the hills. Recently, various folks have tried to do something about this, and come up with Moose, which is an object-oriented framework which implements “real objects” in Perl. Moose is very, very cool technology. It also does its job very well. If you are writing code which is OO-based in Perl, I think there’s very little question that Moose — or one of its derivatives: Mouse, or Badger — is the best tool for the job.

Leaving aside the question of whether an OO-based design is the appropriate pattern for the job at hand though, at the moment, I don’t think Moose and friends are the right tool for the job. Not just yet, anyway.

Why? The primary reason is maintainability — effected through the simple and good old numbers game. Ok, there is definitely a reasonable community of Moose programmers out there. However, within my company, there are very few Moose programmers. If I’m writing code that I expect to live a long time, there are two key criteria — which sound like they should be mutually exclusive, but most certainly aren’t.

  1. Your code should be robust, defensive and error-free.
  2. Your code should be maintainable by someone else of similar knowledge to you in the language in which it is programmed, to allow them to fix it when it blows up and you’re no longer there to tend it.

Now — several years down the line, there are two probable cases. Either: Moose has taken off (or even been absorbed into the Perl core), pretty much any serious Perl coder does Moose, and everything is hunky-dory. Or: Moose is a flop, everyone’s forgotten it… your code crashes at a business critical moment, the unlucky maintenance programmer comes along, reads the first few lines of your application and knows they are going to be having a very long night unravelling your code.

Rule 1 is important in the short to medium term — you want as little trouble caused by your own code as possible, and so robustness and defensive programming wins you that. Rule 2 is the medium to long term game though — mainly because something will change. It might be the platform the code is running on, solar flares or whatever; but your code must be maintainable. Comments, literate programming, inline documentation all help lots — but if the code is written in what turns out to be the bitwise equivalent of Attic Greek, then you still have a bigger problem on your hands.

In short, my message is that we must not be afraid to step away from the bleeding edge at times. Even when the bleeding edge might well hold the best available tools for the job, do you really want to put all your money on that particular foal having a long and fruitful career, or would you rather go for the proven thoroughbred?