We had support call the other day from one of our academic researchers. He was working with one of his old postdocs and they were busy putting a project together based on one of their old papers.

The trouble was that the postdoc was having difficulty accessing the setup they’d originally used. It took a few emails to finally get to grips with the problem; he was using a deprecated server trying to access software that had been updated and made obsolete three years ago. We had archived the software but not completely removed it, we know our staff and the chance of something like this happening was reasonably high.

The thing is that this is nothing unusual. We try to ensure that our staff have access to the most up to date machines and software that their research money can buy, however no-one likes to let go of a setup that has served them well in the past – they simply have too much time and experience invested in it.

To be honest, the only times we get to finally let go of old software is when the manufacturer no longer provides a license for it and server hardware only when the cost to repair is prohibitive. Actually, these days, with virtualisation, old ‘hardware setups’ can often keep going on new metal.

Enabling our staff to use the systems that they are used to, that produce the results in a fashion they understand and can easily work with is a service that we provide. Having to re-learn a package every time it gets updated can be remarkably frustrating to power users (and this applies to Microsoft Office as well as some of the more esoteric suites) and sometimes an update can change the result of a simulation for the worse – not what one needs when one is trying to produce research material from that simulation data.

People can look at our servers and may question why we’re still running them and why they run packages that are several years old. The answer is that we’re trying to ensure that our staff have the services they want as well as the services they need.

It is possible to remove a live system after deprecating it – warn the users and watch the usage level, when it drops to zero for a month or so then take the system off-line. Then leave it there for a year (or some other length of time that has been communicated to its user base). Then mothball it. Then pull it out of storage and recommission it when an academic researcher and his postdoc try to develop a project based on an old paper. Or it could just be left ready to power-up because history has taught us that removing something that still works will require its reinstatement at some point. That point is usually when it takes quite a lot of effort and knowledge-trawling to get it back to its former state – the Law of Murphy is pretty consistent in this respect…

Where do we draw the line between working with Murphy and ruthless efficiency?