COBOL: The forgotten coding language?
Could a sixty-year-old coding language be the next secure job market?
BY: RANDAL REDBERG
When someone talks about coding languages today, you will no doubt hear the terms, Python, Ruby, Java, C++, Perl, and even some newer languages like R, GO, and Swift. When was the last time you heard someone mention COBOL? Yes, the “old school” Common Oriented-Business Language, that is COBOL. It made its debut just over 60 years ago. More than likely the term legacy technology or dinosaur will be uttered if someone mentions COBOL, but think again.
COBOL is still quietly and efficiently running financial transactions behind the scenes after all these years. Over 95% of the ATM swipes use COBOL, and $3 trillion in transactions occur over lines of COBOL code daily. Reuters estimates that 220 billion lines of COBOL code are currently in use. A large number of government and banking institutions still rely on the codebase to run daily operations and service the needs of their customers. Much of the code performing these functions were written thirty to forty years ago.
“Two scientists were key in the development of COBOL in 1959, Mary K. Hawes and Grace Harper.”
So why are big companies still using such an old code language? Cost and time to put it simply. In 2012, according to Reuters, Commonwealth Bank of Australia took the plunge and committed to changing its core operating platform. It was no easy task, requiring the services of Accenture and working with SAP SE to make the switch. It ended up taking five years and cost the company 1 billion AUD or $749.9 million US. So why would a company move off of COBOL if it has worked so well for this many years? Much of it has to do with the lack of people who know the language, not the language itself. That being said, people are still integrating COBOL with platforms like Linux.
The state of New Jersey is scrambling right now to find developers that can help them shore up systems that are being pushed to unprecedented limits due to the extraordinary requests being made to process unemployment claims.
Enter a new era of COBOL developers. Years back, there was a legion of coders who learned COBOL, but the problem now is that most of them have retired or passed away. Where is the next generation of coders going to come from? Cool kids don’t do COBOL, or do they? Despite the lack of interest from a younger generation, companies like IBM are investing heavily in training a new generation to be proficient in COBOL since they still sell an IBM Mainframe with the language running on it. They estimate that approximately 15,000 people are trained each year through fellowships and other training programs. Even with these efforts, younger developers are not flocking to COBOL. Part of it has to do with what COBOL is used for, generating lines of code to perform redundant tasks. No one is going to program a new app or the next social media sensation in COBOL.
“COBOL isn't going anywhere, not for a long, long time.” Gary Patterson
As potential new young developers come onto the scene, no doubt, a new way of thinking will come with it. Stacking and integrating other more robust languages on top of it will more than likely emerge. It also may bring out a whole new breed of developers who like to work in environments that might not have the sex appeal of becoming the next “purple unicorn,” but are happy with taking home a nice six-figure income and retiring with the same company.
So who is to say that this very stable and reliable language won’t survive the next 60 years. Only time will tell. X
“I see a lot of COBOL. My company, Greymine, specializes in IBM midrange (AS/400 / iSeries / IBM i) modernization. We also help port applications between platforms. That means we run into a lot of COBOL and other legacy languages.”
In the case of the State of New Jersey, do you believe that COBOL itself is not able to handle the large number of requests, or was it the way the code was written originally?
I don't know the details of New Jersey's systems other than what I've read recently, but COBOL, per se, isn't really the problem in these organizations running old legacy code. The problem is technology debt, and designed capacity. COBOL started out as a solid, capable language, and has grown and expanded over the years. It is a very capable tool - and programs are written in COBOL, when used and maintained properly work just fine. But, just like an old car, they need proper maintenance. Take your 100% original 68 Firebird 400 that hasn't been properly maintained and run it up to the redline and keep it there for a while and see what happens. Someplace in there, some 50-year old part is going to fail.
When we work with these very old, out of date legacy systems, regardless of programming language, we generally find at least some of these common issues:
Original architects and developers long gone,
Poor original design, even based on the standards of the time. (I've heard this referred to as "low bidder syndrome" in government software projects.)
Lost paper documentation,
Undocumented changes and fixes,
Unresolved long-term defects,
Old, outdated computer hardware, operating systems, and tools,
Inadequate change management and testing processes,
Lack of performance and load testing processes,
Lack of available skilled resources (at a price the client is willing to pay, that is).
Lack of creativity in bringing in fresh IT talent and encouraging and rewarding willingness to dive into these legacy systems, learn them, and improve them.
"If it ain't broke, don't fix it" attitudes in senior management.
Some of the largest financial transaction processing systems, healthcare claims, telephone billing systems, utility billing systems, etc. in the world are COBOL applications running on IBM mainframe or IBM midrange hardware. They handle daily transaction loads that I'd be willing to bet exceed what some of these state employment systems handle in a year. It has absolutely nothing to do with any limitation in the programming language itself.
System failures like this have -everything- to do with the capacity these systems were designed and (possibly) tested to deal with, and just about nothing else.
Speed to react to these problems has more to do with poor management of these software products over time: inadequate documentation, poor design, "low bidder" procurement procedures, poor change management processes, lack of adequately skilled staff, low average pay levels for developers and contractors, limited state budgets, and "if it works, don't fix it" attitudes.
Why would someone move off of COBOL if they had access to competent developers who knew the language? I know it’s old but it obviously still works.
Platform costs, and lack of skilled developer availability, or fears about future developer shortages. IBM mainframe is expensive to acquire and maintain compared to other platforms, and requires technical skills to operate, program, and maintain that are getting harder and harder to find.
Lack of "cool factor": COBOL is considered by many developers, especially young developers, to be "old-school" - outdated technology, and it is definitely not cool. It is rarely taught in modern programming courses in college, so programmers have to learn on the job, or in their spare time - and many see it as a big backward step.
Could the code be written in a way to be just as robust as newer languages?
Robustness isn't about the programming language. It is about software design, development, and maintenance practices. I've seen really good COBOL, and terrible, impossible-to-maintain Java. Different languages have different benefits and drawbacks, and programmers tend to be more productive in some languages than in others, but I'd take a very well-designed and coded COBOL application over a poorly done C# program to do the same function every day.
What are the limitations of COBOL and what code platform would someone likely move to if they did make a change?
Legacy COBOL is a simple, wordy, procedural language. It can be made to do just about anything, but it doesn't come packaged with a lot of components that developers take for granted in more modern languages. So it is often complicated to do common tasks, like sending an email, or calling a web service - often taking hundreds or thousands of lines of code to perform a function that can be done in Java or C# in a few lines of code.
COBOL doesn't offer native support for multithreading, versus modern languages (and some legacy languages) that have the ability to simultaneously run multiple threads. This makes COBOL less suitable for tasks like web application serving. Legacy COBOL has limited support for complex data types and doesn't handle variable-length data (like XML and JSON) very well. It doesn't directly support graphical interfaces.
COBOL often moves to COBOL, just to a more modern flavor, programming style, and, sometimes on a different platform. I've seen a lot of mainframe COBOL move to IBM midrange (IBM i / iSeries / AS/400), which is cheaper and easier to operate. And there are COBOL development environments and compilers for almost every major OS, including Windows, Linux, AIX, and Unix - which include modern tools, access to libraries of common functions, GUI interface development options, and other of the productivity features found in modern programming languages and development environments.
In recent years, IBM provided guidance to COBOL users, on both mainframe and midrange hardware platforms to consider moving to Java, and provided Java environments and tools to help facilitate Java programming on IBM hardware. Obviously, IBM wants to keep the hardware and OS sales and support revenues associated with those platforms, and offering a Java option was a good way to do it. But you can find companies that have ported code to most popular programming languages: Java, Microsoft .NET languages, LAMP stack, etc. These decisions are often based more on the available skillset in the organization than on some abstract "best" target language. If the new CIO is a Microsoft fan, it is going to be .NET. If they are an open-source advocate, maybe LAMP.
These large legacy systems are very expensive to port to another language, so another common approach is to simply buy and migrate to packaged software or migrate to a Software as a Service (SaaS) provider where suitable applications exist.
Another modernization approach is to repackage the existing COBOL programs into web services, or some other form of API, that can be used by new programs written in other languages. The core business logic stays in COBOL, but UI, printing, and other services are developed in a more modern language that provides better support for graphical interfaces and web interfaces.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.