12 October 2010

Knowing when to change

By Andrew Clifford

One of the big challenges for the long-term management of systems is deciding when to adopt new technologies.

If you want systems to be long-lived, you need to pick technologies that are technically and commercially viable. You need to use technologies in a standard way, to make sure that you keep on the upgrade path and that you can swap to other technologies if suppliers fail.

You also need to make sure that the original technology decisions are respected. There will be a constant pressure to adopt this or that new technology. Adding a component that then fails technically or commercially can undermine the entire system and force expensive redevelopment.

However, if you defend your original decisions too enthusiastically, you might not adopt new technologies when you should. You might condemn your system to premature death.

We faced this problem with our Metrici Advisor software. Because it is the basis of our business, we have to make sure that is is long-lived. Also, since Metrici Advisor helps people manage their systems for the long term, we have to show that we know what we are doing.

When we started development in 2005 we made some choices. The system is Java based, running in Apache Tomcat. We use the MySQL database, but do not use any non-standard features. The web pages use only standard HTML and CSS.

We decided not to use any JavaScript on the web pages. JavaScript is easy to get wrong, particularly with the browsers of five years ago. There were no generally accepted frameworks or standards for JavaScript. It was a skill that we did not have. Using JavaScript would have undermined our attempts to make the application simple and standard. Rightly or wrongly, we decided that our system would be better without it.

Over the past five years, I have defended the absence of JavaScript. During that time, though, web applications have improved, and ours now seems rather clunky. We lack the visual effects, gadgetry and dynamism that people now expect. We risk falling behind.

Over the same period, JavaScript has evolved. A lot of JavaScript is now developed using the jQuery library, which is becoming a de facto standard. Without going into the details, jQuery provides a much easier and more standard way of using JavaScript to add visual effects, gadgetry and dynamism without disrupting the overall design. It overcomes many of our original objections to JavaScript.

We have therefore decided that the time is right to adopt JavaScript and jQuery.

Was I wrong to defend our original decisions for so long? That is a difficult question. We could have adopted jQuery a couple of years ago, but if we had not defended our original decision robustly, we would have been just as likely to have picked a different library or developed our own framework, which would have left the system in a mess.

Managing systems to be long-lived is hard. You have to defend the system from the vagaries of fashion, and you have to disappoint constantly those who want you to adopt the latest and greatest technology. Conversely, you must adopt new technology when the time is right. It is a difficult balancing act.