Interesting but not at all surprising:
70 per cent of firms rely on legacy systems put in before 1996, says survey
With all the hoopla about Web 2.0 and start-ups it might give the impression that most of IT is taken up by writing new code and products. In reality most jobbing programmers are maintaining and extending existing systems rather than new projects. Many times something stable and well-understood is much easier to learn and use simply because of the pain that your peers have gone through to get that stability before you, things that have been around longer tend to have larger pools of developers with experience, more support/documentation available etc. so although they may be ‘old’ they’re not necessarily worse than something new. For every successful startup there are many failures, business entrepreneurs just fold that experience into their portfolio, learn from it and make the next project better but how about the IT folk? Technologies change all the time, you can make the same general mistakes but in a fast-changing environment yes you may be battle-scarred from a previous project but how much practically you can take forward can be tricky if the next project doesn’t have something in common with what you’ve worked on before even basics like platform/language.
The downside of maintenance is the real drain on productivity, a particular headache I find working with legacy systems is a malady that takes many forms, I call it “versionitis” – the versions of the product in use in a system are older than the vendors recommended release version and faults are indicating that an upgrade should fix the problem/improve performance/security. Snag is products these days tend to be an amalgam of multiple other third-party elements. Say you have 3 components one gets upgraded but second component isn’t compatible with the upgrade, wait around for 2nd component to upgrade then 3rd breaks…and so on you can go round in circles and never move forward. With Open Source you could have a go and try fixing it yourself but when you are relying on a paid closed-source vendor you’re pretty powerless. You have to watch upgrade notices like a hawk to try and find that Nirvana where subsystems sing in perfect harmony like the Coke advert. But you can gobble up oodles of valuable time experimenting trying out patches and upgrades, backing up, rolling back. Not all upgrades are good news, it’s fairly common for a new patch to also inadvertently introduce a new bug that is in fact more serious than the original fault you were trying to fix.
Who can blame vendors for wanting to improve the baseline code customers use by encouraging upgrading to bug fixed, feature enhanced versions? Fewer support problems…for them. In practice it’s it’s not always feasible or even possible from a resource point of view to make the change. I’ve run into a small version of this recently where we’re using a product that the application vendors strongly recommend using a particular version of DB as that’s all they support and can guarantee the product is tested under(?!), the snag is that third-party DB vendors have stopped offering support and have withdrawn the binaries/sources for that version which is now over three years old. So there’s no easy way for me to create a testbed for the product with that DB version, what can I try? How about trying the nearest point version and hope for the best that the application and the database get along without trouble? It’s frustrating when you don’t have control over the ingredients for the recipe for success.
