It is eight years since COBOL celebrated its 50thbirthday, and another two since I last discussed the idea of including COBOL on a university syllabus, so as the legacy language heads towards its golden years, where does it sit in today’s IT landscape? There are more COBOL transactions executed in a day than there are Google searches is the latest statement that is espoused by the COBOL advocates, and that could well be true, but are there really any organisations out there that still actively develop in COBOL?
Sadly, the answer is Yes, though these are becoming a rarity, and even those passionate about COBOL now accept that its applications need to be supported and maintained, rather than added to. All of this leads us to the inevitable conclusion that there is still a need for COBOL programmers, so where will they come from?
Many COBOL programmers have now hung up their coding pads and retired on the pensions built up during the COBOL contracting heyday of the 90s. Others have found alternative employment, often beyond the frequently bewildering landscape that is the modern day IT department.
But those applications, lovingly created and nurtured over decades of constant change, still need to be cared for.
There is one school of thought that suggests that by giving C# and Java developers a common development environment for COBOL, they will quickly pick up the skills required to support these critical applications, but I am sceptical about the appetite for this. They may decide that a few lines of OO COBOL to change the look and feel of a GUI is a funky thing to do, but what about the huge monolithic batch applications that still abound in many large organisations? COBOL 68 or 74 anyone?
So are we faced with a skills gap that could potentially rival the hype that surrounded the last great IT problem, Y2K? Hopefully not, for there is a solution out there.
Rather than looking to employ COBOL developers, organisations should offer a career path to university graduates, the first step of which could involve COBOL, PL1, and any other technologies that still require TLC.
The idea is not a new one; I know of at least two companies that have been doing this successfully for many years, and that is the key. This is not a one off exercise, and requires investment from the organisation as a whole, not just IT.
The recruitment process is obviously important, as the selection criteria should not necessarily focus on Computer Science and other technology related degrees. Indeed, this can be a hindrance as those studying Java at university are unlikely to look at a career that starts with COBOL as a positive step.
The career progression starts with the core legacy technologies, as the students learn from the bottom up. I know from personal experience that there are many things that old developers take for granted, but which are alien to the youngsters of today, for instance the concept of carriage return / line feed!
The early part of their career is spent understanding, analysing, supporting and modifying the vital legacy applications, whilst also gaining an understanding of the other facets of the business, such as marketing, finance, supply chain, etc. The introduction of newer technologies into their curriculum is often seen as an exercise in dual skilling, but the reality is that once they are proficient in, for instance, web technologies, the continued support of COBOL is given rather grudgingly!
Others from the graduate intake may move into analysis, project management, or other disciplines perhaps not even connected with IT, and so it is important that the recruitment process starts again in plenty of time to sustain the flow of talent.
The training programme should be largely delivered in-house, although there are companies out there who will still deliver training in legacy skills (including Legacy IT Consultants Limited!)
