If you have been following the news lately then you might have heard that the current strain on our government websites has caused a massive increase in the need for COBOL developers. So much so that we are taking folks out of retirement and putting them back to work writing scripts that they thought they left behind in the 80's.
And nothing interests me more than hearing non-technical folks discuss our technical infrastructure and make societal choices that can impact future generations.
So today, I want to dig a big deeper into this current problem and see if it holds any merit, and if so, what we can do about it. And if you need to put a pause on your current React course and pick up a COBOL 60 textbook to prepare for our new future. Probably not.
What's the issue?
The recent pandemic has caused a relatively enourmous amount of people to jump on to the various state unemployment websites, as unemployment is rampant now and might be so indefinitely. Hence, unemployment goes up, traffic to the website goes up. Not forever, just while unemployment goes up.
The assumed issue is that these systems are relatively old and running on COBOL, a relatively old programming language that isn't aging very well, and the number of developers that are familiar with COBOL shrinks by the year.
And as such, these websites can not handle the workload and are consistently not functioning as intended and requiring maintenance on regular schedules.
I have personally tested out the website for California, and it is pretty accurate. It's offline pretty frequently and it might stop working midway through filling out a form. The websites themselves are running in .NET from the looks of the URL paths. So the issues I'm assuming are from internal scripts that rely on COBOL.
But really that might just be due to the large number of visitors on the website at any one time. This isn't necessarily the direct result of using COBOL. Most websites online today probably could not handle tens of thousands of concurrent requests hourly. So potentially, it could be a hardware issue intertwined with a lack of knowledge on the software side.
What is COBOL?
Let's get into it. Because there is much to discuss here in terms of what COBOL is and if in fact it is as terrible as many senators say it is.
COBOL is a programming language. It stands for Common Business-Oriented Language as it is mainly suited for developing business and financial applications. And yes indeed, it is in fact relatively old from a programming language perspective.
The language was developed as a US Department of Defense effort to create a more portable and higher performing programming language during the early 60's.
The first version of COBOL was released as COBOL 60 with each successive version, COBOL 61, COBOL 65, etc iterating on the old versions and fixing flaws along the way. The language itself is compiled and is mainly deployed on mainframes allowing for its high performance benchmarks making it very popular for crunching large data sets in the financial districts.
It stands out due to its English-like syntax, which was intended to make the language more readable and thus quicker to write code. However, with over 300 reserved keywords most being proprietary to the language, it lends itself to being more verbose than anything. Take the following typical coding line for example:
y = x;
The COBOL equivalent of that statement would be the following:
MOVE x TO y
It shares similarities to lower level languages such as Assembly in this regard. Here is another more drawn out example that should paint a better picture of the language.
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY 'Hello World'.
STOP RUN.
If you can guess what that script does, congrats. And if not, then fret not, as again the language steers towards the English language, which for a modern day programmer currently, this is uncommon. The script essentially displays "Hello World".
The language itself was developed in part by a steering committee comprised of 6 of the top computer manufacturers, including IBM, Honeywell Labs and RCA as well as 3 government agencies which included the US Air Force, the Navy's David Taylor Model Basin and the Natural Bereau of Standards.
By 1970 COBOL had gone through various iterations and had become the most widely used programming language in the world due mainly to its overall speed and portability as more and more manufacturers were in the process of developing compilers for the language.
It is estimated that by 1997 over 200 billion lines of COBOL code ran in the corporate sector running roughly 80% of all business programs. I would imagine that we have hit the trillion mark where we currently stand.
In 2002 COBOL received the approved specification for adding object oriented features into the lanuage.
By 2017 it was estimated that 43% of all banking systems used COBOL. So needless to say, the language has a very long and complex history that is ongoing and constantly shifting to this day.
The issue (again)
Knowing a bit of the history and seeing some of the syntax, let's discuss the issue again, because maybe you can see it with slightly different eyes now.
It is true that the language is old and developed with older standards in mind. But this is true of anything. Take our subway systems in America as an example. Most are decades old and comprised of decommisioned tracks, abandoned carts and inefficient network paths. But they still work. They still transport millions of people yearly to and from their desired locations.
Can we slowly phase out these older systems and replace them with new ones? Absolutely. But we can not do this overnight. Abolutely not.
Replacing hundreds of billions of lines code that power the infrastructure of an entire nation is akin to replacing every gas car on the road with an electric one. Sure, it sounds like a progressive plan that we should be considering. But we have to look at the peripheral side effects of doing so. In the gas car example that would include increased demand and production of lithium ion batteries, replacing all gas stations with electric stations and potentially rebuilding all roadways to account for the massive weight demands as electric cars can weigh up to twice as much as a standard gas car.
That same analogy can be used for potentially phasing out the most widely used programming language on the planet with something else. What that something else is, we have not discussed just yet.
The real issue
Now let's get down to the real issue with this situation. And that is the fact that it is getting harder and harder to find COBOL developers in 2020. Because the language and the mainframe are pretty stable already, so that's not the issue. They have been worked on for decades and IBM makes pretty robust and powerful mainframes currently.
Note, this is not a brand new issue either that only affects COBOL. This is not the only programming language that is facing that problem. Certain languages have deficits in the number of developers that actually know it. The more a language is used, the more developers that you will need. That's pretty basic logic. If those languages are not commonly taught however, you will not have a skilled labor force in that department.
I personally faced this issue in 2008 when working with a lesser known ERP system that relied on the X++ programming language. A language with zero documentation and that required very expensive training in order to grasp the fundamentals.
COBOL is not taught in most Computer Science curriculums currently, as either C++ or Java are the defacto language at many universities. And since most real-world applications running in COBOL run on mainframes, you would also have to figure out a way to get your hands on an IBM z/OS device. Not an easy task by any means.
And my last point on this, is that the current increase in demand is only temporary. In a few months, when things begin to move forward again and website traffic goes back to normal, we will no longer be talking about COBOL. It will still power most of our financial infrastructure and it will still continue to get updates although more slowly. But just as in 2018 and in 2019 no one had heard of the language, so too will we forget it in 2021 and in 2022.
If we are to actually begin to find more stable solutions, then we really need to look at how we handle education in the technical sector. We need to learn to respect our infrasctucture instead of cowering in fear away from it.
I hope this article provided some clarity on the current discussions being had around the country on our digital infrastructure. And hopefully we stop blaming a language that was built by historic people with the intent of powering a country and begin to look for actual solutions instead, such as increasing awareness and improving the way that we educate future generations on such matters.