Cobol cabal will take over
THE WORLD Australia
Old skool is cool, Cobol h8ers
The old advice was “Go west, young man”... but it seems the new one should be “Learn Cobol, youngster”.
That at least is the implication of a report from Australia on the languages and environments that are heavily used.
The Sydney-based Object Consulting has released a paper detailing those languages which will no longer be supported in the near future, including the likes of .NET 2.0, J2SE 1.4 and Cold Fusion (according to Object Consulting they have a three-year shelf life), while anything on Smalltalk or FoxPro should be junked or moved to a new system immediately as a result of non-support and no further development of the environments.
Other applications that should be retired immediately include those written in Java 1.1, J2SE 1.3, RPG, and Pascal.
Such advice might not sound all that surprising from a company that aids business in moving from older to newer architectures: nor might the chipping in of Micro Focus Australia on the same point.
Despite such obvious drumming up of business, there is indeed something of a problem. There are still huge numbers of systems running on older architectures and there aren't all that many people still around who know how to modify them.
All of the big four banks in Australia use Cobol, as well as 50 per cent of the tier two, all of the large insurers and 70 per cent of the second-line ones. Some 50 to 60 per cent of government agencies also use the language. But none of the young people coming into the industry seem to be learning it, or any of the other old languages, like Fortran or Delphi.
Kevin Francis of Object Consulting has said that those who do know how to use these older technologies are able to charge seemingly ludicrous rates.
Francis said: “I have seen examples of developers on older technologies like RPG and Delphi charging twice the rate of a developer on a newer technology.“
From the point of view of the companies and institutions, this is a problem. The longer they wait to modernise these systems, the more it is going to cost them when they do – for they will need experts in the old to explain what the heck the systems do to those attempting to modernise it.
The costs of such modernisation are nothing compared to the costs of having a major system actually go kablooey at some future date when the language or architecture has no one at all left who understands it. And this is apart from the difficulty of finding people to do maintenance or routine modifications.
So while modernisation might be a good idea from the point of view of the users and owners of such systems, the actual advice we might give to a newly minted young shaver fresh off the programmers' production line might be: learn as many of these old languages as you can. Be the only youngster who can deal with them: they're not all going to move off these systems for decades yet (never, ever, underestimate the immobility of a large financial company) and your competition for the consulting jobs seems to be lining up for the graveyard.
Sponsored: Becoming a Pragmatic Security Leader