I stumbled across an article about COBOL dating from 2020, and I thought it might be useful to clarify a few points. The article is What Is COBOL and Why Is It in Demand? by Jennifer Seaton, published on the Make Use Of site.
COBOL Renaissance
The author is quite right to mention that job opportunities for COBOL work are on the rise. There are two reasons for the resurgence of COBOL.
First, the older workers who have been maintaining legacy applications are retiring (or worse). Those applications are critical to the operation of the global economy and to many national governments. Companies and government agencies have been trying to replace them for many years, with mixed results (mostly bad). Some of the key systems are here to stay. They need support.
Second, IBM’s Mainframe Modernization program, which has been making steady progress for more than 20 years, is really gaining traction. Everything about the mainframe platform from the hardware up has been revamped. Demand is rising for software engineers to modernize legacy applications. That work involves knowledge of traditional mainframe programming languages, of which COBOL accounts for nearly all the production code, combined with knowledge of contemporary technologies – particularly cloud technologies and Java, but also others.
The Tale of New Jersey
Dr Seaton mentions a situation that hit the tech news during the pandemic, when New Jersey governor Phil Murphy lamented the shortage of COBOL programmers to upgrade the state’s unemployment compensation system. The system received an unexpected bump in traffic owing to the pandemic lock-downs and layoffs.
That story received a lot of attention for a while, but the problem was not about COBOL. You can’t quickly “fix” an application so that it can handle ten times the normal workload. COBOL has a long history of supporting extremely large workloads reliably and smoothly. The problem had more to do with infrastructure and system architecture than with the programming languages used to build the applications. Hiring more COBOL programmers for the short term would have done nothing to provide more-timely unemployment compensation processing for New Jersey workers. Even if some code changes might have helped, they couldn’t have been delivered before the pandemic ended.
At the time, I followed up on the call for COBOL programmers in New Jersey. I found exactly one job announcement. They were recruiting for one person. One. That’s all. The terms required the candidate to relocate permanently to New Jersey. They required the candidate to work on site at the state’s facility during the most dangerous period of the pandemic. They offered a maximum pay rate of $40 an hour; completely out of line with both the cost of living in New Jersey and with general pay rates in the software industry, and oblivious to the natural effect of supply and demand on labor pricing.
That is not a serious job offer even in normal times. They were never serious about hiring people to address that problem. The story is only a fable, misunderstood and exaggerated by just about everyone who ever mentions it.
COBOL vs. C Smackdown
I’m not sure of the value of comparing C and COBOL, but the author says: “Much like C, COBOL is a procedural programming language.”
But COBOL isn’t much like C. A stronger comparison could be between COBOL and Java. The characteristic of COBOL that led to its capturing most of the market share for business application development is that it (mostly) protects programmers of average skill from making memory-management errors. That’s what programmers of average skill spend most of their time doing, unless they’re using a language that (mostly) handles memory management for them. It’s the reason Java became the dominant language for business application development from the late 1990s on.
To illustrate why COBOL is often described as “verbose,” the article provides this example of an assignment statement in C:
int result = 1 + number;
In contrast, this COBOL statement is presented:
<p “style=”font:Courier New”>
ADD 1 to number GIVING result
I don’t think that’s a very good example. For one thing, the COBOL statement isn’t verbose. I’ve seen (and written) a lot more verbose COBOL code than that. It is, in fact, the most verbose language I know. More verbose, even, than Java – and if you’re familiar with Java, you know that’s really saying something.
But that example fails to make the case. You can write the same logic in COBOL this way, too:
<p “style=”font:Courier New”>
compute result = 1 + number
Not a whole lot different from the C example, is it? In any case, COBOL really is verbose. That much is true. It’s just that the particular example doesn’t show it.
By way of an explanation of why COBOL’s popularity waned in the past, the author writes, “There are more programming languages today that centered on English commands that have a lot more features than COBOL.”
I struggle to make sense of that statement.
I’m not so sure there are many programming languages centered on English. Certainly, none of the mainstream languages in use today fits that description. It seems to me COBOL was primarily used on IBM mainframes and midrange systems, plus a few other midrange systems, by 1990. The 1990s were a time of industry fads and misguided attempts to replace mainframes with cheaper equipment. The capabilities of mainframes that made them compelling for large corporations and governments were not easy to support using other technologies of the day. On the application side, the 1990s saw various fads come and go, including CASE tools and client-server application tools like PowerBuilder. They also saw programmers who didn’t understand memory management or threading trying to work with C, C++, and Objective C. There was considerable thrashing.
By 2000, we had Java and new solutions were emerging, such as Microsoft’s .NET platform, that provided a runtime environment to handle memory management, threading, and garbage collection so that application developers could spend far less time and effort on those things. The shift wasn’t about “English commands” at all.
“That’s a Spicy Meatball!”
I couldn’t resist a reference to the 1969 Alka-Seltzer commercial (YouTube).
The article states that a “criticism of COBOL is that programmers had a tendency to write spaghetti code. Spaghetti code is a derogatory term for code that is poorly structured. The primary culprit of poorly structured code was the GOTO command.”
A couple of clarifications are in order here.
First, the GO TO statement was considered a bad practice from about 1970 onward. To say this is still a concern for COBOL code is absurd. It has been a non-issue for longer than most of you have been alive; in some cases, longer than your parents have been alive.
Second, in my work as a technical coach, I’ve had many opportunities to examine and work with existing code bases in many languages for well over 20 years. I can assure you the majority of spaghetti code is not to be found in legacy COBOL applications in large enterprises.
The individuals who chose to stay with the mainframe after the exodus to smaller systems in the 1980s-1990s were those who understood and cared about the platform. They were and are some of the top programmers in the world. They don’t do “spaghetti code.” If you want to see spaghetti COBOL, look at “vendor” code that companies inherited after the vendors went out of business.
If you’re hungry for spaghetti code, the place to find it is in code bases that were built during the years of rapid delivery with little attention to quality – the 2000s to the present. The driving force behind all that code was speed to market. Development teams skimped on unimportant factors like testing, maintainability, and security. They got “something” to market as quickly as possible, and then patched it piecemeal as support tickets came in. And they weren’t coding in COBOL.
Many teams today still operate that way. The general quality of software worldwide testifies to the effectiveness and the popularity of that approach. If you want to argue that point, do it by showing me a world not full of Windows blue screens of death on billboards, HTTP 500 errors on kiosks, Linux boot errors on train and bus signage, and web/mobile apps that don’t work. Meanwhile, the back-end (mostly COBOL) systems responsible for your money are pretty solid. So yes, please, argue the point.
Why Learn COBOL?
The article purports to suggest reasons for a young professional to learn COBOL. The sales pitch is that COBOL is not “trendy” but it is “important.” She suggests that if you were thinking about learning a programming language but needed a push, then consider learning COBOL. Let’s set aside the question of whether it’s a good idea to have people who “need a push” getting involved with “important” computer systems, and think about why a well-motivated software professional might consider COBOL.
People do want to work on systems that provide value; that speaks to the point about importance. But technical people need work that is meaningful to them, and that provides interesting opportunities for career growth. COBOL considered in isolation from its context doesn’t offer that. But the IBM Z system has evolved into the single most capable and powerful computer system ever built. It isn’t used solely to support legacy applications. It’s basically a network in a box; a whole cloud infrastructure in a box – not just a single server.
It’s a system we can’t buy for ourselves and practice on at home. If you can get a job working on one of these systems, that job will open doors to further opportunities for technical career growth. Supporting legacy applications is part of the job, but the modernization aspect is probably the largest part. That’s where you’ll find opportunities to work on the latest technologies at extreme scale. It’s hard to think of a more compelling resume-builder than that kind of experience. COBOL could be a way in.