Click here and learn how to make money from them today!
The world’s banking, business and governmental systems are underpinned by a programming language developed over half a century ago – but fewer people than ever know how to use it today.
Devised in 1959 by Dr. Grace Hopper and her team, COBOL has endured the passage of time extremely successfully, with over 220 billion lines of code still in use today (and counting). If not for FORTRAN, which was invented five years earlier, COBOL would hold the title of world’s oldest active programming language.
COBOL’s beauty, according to its proponents, is in its simplicity, stability and reliability, which allowed the code to be adopted far and wide when it first hit the scene.
“COBOL was created before there were software engineers or developers as we know those titles today,” notes Barry Baker, VP IBM Z Software. “It uses English words and was designed for business users. As such, it was easy to use and get started with, but also easy to read, modify and debug.”
However, using a decades-old programming language – no matter how reliable – also has its downsides. Systems go without maintenance or upgrade for years longer than they should and staff churn rate means the original developers are likely long gone.
Despite its antiquity (especially in the context of computing’s brief history), the language continues to prop up mission-critical systems in the public and private sectors, which means the worsening skills shortage could have devastating effects, universally felt.
What is COBOL good for?
COBOL runs primarily on mainframe computers, which governments and large enterprises have historically leaned upon for compute-intensive workloads such as batch processing, data analytics and large-scale accounting functions.
Today, cloud computing services such as AWS and Microsoft Azure are capable of performing these same kinds of tasks, without the need for physical hardware that both takes up space and can also prove expensive to maintain.
Despite the emergence of cloud computing, though, the mainframe market is alive and well – which means COBOL is alive and kicking too.
Two firms play an outsized role in the upkeep of COBOL and are considered by many to be the custodians of the language: IBM and Micro Focus.
IBM dominates the mainframe market with the IBM Z, which has now been interoperable with the cloud for a number of years. Announced in September, the latest iteration (IBM z15) is designed expressly to support hybrid cloud environments and is capable (with the help of COBOL) of processing one trillion transactions per day.
Micro Focus, meanwhile, provides COBOL-specific development and modernization tools to organizations reliant on the language.
Ideally suited to processing records and parsing large volumes of data, COBOL is most often found in the finance, telecoms, aviation and healthcare sectors – as well as in government systems.
“It is a language that was specifically built to be easy to use for encapsulating the application business logic and accommodating the transaction processing requirements of the core infrastructure systems that serve many organizations that operate in these sectors,” explained Bola Rotibi, Research Director for Software Development at analyst firm CCS Insight.
“There are very few financial applications and transactions around the world that are not served either wholly or in part by a COBOL application, even in today’s digitally enabled operations.”
Indeed, according to figures from Reuters, 43% of US banking systems are built on COBOL, while a whopping 80% of in-person transactions and 95% of ATM interactions rely on the language.
IBM Z mainframes, meanwhile, process circa 87% of credit card transactions, $8 trillion in payments and 4 billion passenger flights each year, claims IBM.
COBOL has also been iterated upon numerous times since it was first developed, which, according to Baker, is “a key measure of determining the vitality of a language.”
Older COBOL applications, for example, can be easily recompiled and run in the cloud, or in established environments such as Linux and Windows.
What isn’t COBOL good for?
It’s true that COBOL would not have stood the test of time if it did not fulfil a broad range of functions – and fulfil them well. But it has its limitations too.
“COBOL works well for what it was designed for” is the common refrain among those with the most intimate knowledge of the language. In other words, the code is poorly suited to a number of modern use cases that arose after its creation.
For example, designed long before the internet existed, the language is not equipped to facilitate the level of interaction and dynamism required by mobile and web applications.
According to Baker, as new workloads emerged, COBOL had to concede its position to newer languages, such as Python and Java.
“Programming language popularity ebbs and flows due to changing developer preferences, the emergence of new programming styles (like object-oriented programming) and new types of workload/computation (like high performance computing, analytics and machine learning),” he said.
Modern programming languages are also tighter and more efficient than COBOL – a boon for developers working under time pressure
“[COBOL] was and continues to be verbose,” Rotibi told TechRadar Pro, “meaning that many more lines of code are required to execute a command than other languages.”
Even in scenarios in which COBOL is expected to thrive, the language’s long legacy has proven problematic.
In recent months, COBOL-based systems were found incapable of keeping up with the number of unemployment claims received by multiple US states, as unemployment skyrocketed in the country as a result of the coronavirus pandemic.
The lack of available COBOL developers forced Governor of New Jersey, Phil Murphy, to issue a public call for volunteers able to code in the decades-old language. “We literally have a system that is 40-plus years old,” he complained.
The poorly-optimized and outdated system relied upon COBOL code written years ago and was causing a serious delay, and the knock-on effect on the lives of applicants was doubtless significant.
Adrian Keward, Principal Solution Architect at open source software firm Red Hat, believes organizations are hesitant to meddle with years-old COBOL systems, in part because they have always functioned perfectly well. However, this has led to a dangerous attitude to system maintenance and renovation.
“Lots of [COBOL] code is still in use, but fewer people understand it these days. As a result the language tends to be left alone until replacing it becomes necessary,” he explained.
“As the majority of COBOL code has not been touched for many years, businesses commonly use the approach ‘if it’s not broke, don’t fix it’.”
Why did COBOL go out of fashion?
Of the developers that are still familiar with COBOL, many are moving towards the twilight of their careers; only 11.5% are under the age of 35, while 18.8% are 55 or older.
The popularity of the language has been on a steep downward trajectory since circa 2002, falling from 5th most popular programming language to 33rd, although it has admittedly enjoyed a mini resurgence in recent years.
So, how could a language used so widely, for such a vital set of use cases, ever be allowed to drift towards obscurity?
A number of factors are at play, but chief among them, the simple fact that COBOL was no longer considered sexy by up-and-coming talent in computer science. To at least some extent, COBOL was toppled from its perch by the changing winds of preference.
According to John Pyke, CEO of legacy migration firm CIMtrek, “IT is a fashion industry, with new graduates eager to work on the ‘next big thing’. Usually in languages such as Java and C# – with the applications produced being very interactive and API-driven.”
Cycled out of fashion, universities were also disincentivized to run COBOL courses. This served to aggravate the problem, which would only rear its head years down the line, when the skills shortage among younger developers began to represent itself in the workforce.
“COBOL drifted out of fashion for two reasons,” suggests Keward. “Firstly, there is a lack of universities running courses that teach students how to approach and master COBOL. Secondly, technological advancements moved operations from the mainframe to the client server and Java language gained notable traction. Innovation won out over stability.”
In a bid to rectify the skills imbalance (and presumably to prolong the life of the language from which they profit), both IBM and Micro Focus have launched separate revival initiatives.
Prompted by the pandemic, IBM rolled out a brand new course designed both for beginners and professionals requiring a COBOL refresher. It has also launched an initiative designed to connect COBOL programmers with potential employers.
Identifying a downturn in COBOL expertise, Micro Focus collaborated with businesses and universities to establish the COBOL Academic Program, which provides free access to the latest teaching tools.
The company also hosts a COBOL Programmers Facebook Group, with around 15,000 members. “Dinosaurs, COBOL Programmers established and new, and other slaves of the code are all welcome,” reads the About page – which says more about the language than perhaps anyone could in 2,000 words.
What’s preventing businesses moving on from COBOL?
The most significant barrier facing businesses looking to reduce their reliance on COBOL is the volume of code in circulation. The process does not necessarily pose an insurmountable technical challenge, but certainly presents a logistical one.
According to Pyke, the magnitude of the situation could be compared with the Y2K fiasco, that saw organizations scramble to alter their computer systems to accommodate a year that required four numbers to be properly differentiated (i.e. 2000, instead of ‘99).
“Think back 20 years – the amount of money and resources put into reducing the impact of Y2K should give you an idea as to the herculean task of replacing the dependency on COBOL,” he said.
Banking giant Capital One is among the large enterprises desperate to minimize their dependence on the language and is currently undergoing the extensive work necessary to shift away from the mainframe.
“Operating mainframes is not only more expensive than the cloud, mainframes also lack the ability to rapidly scale features and do not allow companies to take advantage of open source,” said Joseph Muratore, VP Technology at Capital One.
“We are aggressively working to modernize our last remaining mainframe applications to reduce and eliminate Capital One’s dependence on COBOL…Many companies underestimate the comprehensive all-in nature of this kind of transformation,” he added.
In the case of Capital One, the sums align in such a way that it makes sense to move away from COBOL and the mainframe, but this will not necessarily be the case for all businesses dependent on the language.
“In most cases, an organization has made significant investments in their COBOL systems over time, including developing additional IP and processes to support it,” Micro Focus executive Derek Britton told TechRadar Pro.
“These core systems are enabling real benefits and generally touch business-critical data. Ripping them out and starting from scratch thus may degrade the ROI on those investments and put critical revenue (or cost savings/risk mitigation) at risk.”
In fact, according to a recent Micro Focus survey, a large proportion of businesses have no intention of wholly abandoning the language – perhaps due to the gravity of the task or perhaps the expense.
Over two thirds (70%) of enterprises surveyed said they favored modernization as an approach to implementing change, as opposed to ripping and replacing key COBOL applications.
Almost all respondents (92%), meanwhile, said COBOL remains of strategic importance in new ecosystems. All of which suggests the world’s second oldest programming language is here to stay.
For organizations whose economic relationship with COBOL means that shifting away is impossible (and those for whom the language still fulfils its function perfectly well) the only solution to the skills gap dilemma is a commitment to training staff and to acting on maintenance needs long before systems malfunction.
Without these vital measures, organizations could well find themselves with a host of critical COBOL-based applications, but with no one to maintain them.