COVID-19, COBOL, and Y2K

One of the grim ironies of a disaster is the way in which it reveals just how little has been learned from past disasters. In some cases, these unheeded lessons reveal themselves in ways that have cataclysmic or gut-wrenching consequences, and in still other cases these failures to learn from the past go easily overlooked against the backdrop of the larger unfolding crisis. When the history of COVID-19 is written, journalists and academics will devote pages upon pages to the ways in which this crisis demonstrates a failure to heed the lessons of past calamities, but they may forget to include the case of what has recently transpired in New Jersey.

As the COVID-19 crisis intensifies, millions of people have lost their jobs, and as a result they have been flocking to the websites that their states use to process unemployment claims. In several states these sites have been overwhelmed by the massive number of applicants. Yet, in New Jersey this story has taken a somewhat odd turn. Indeed, while many states have put out calls for N95 masks or medical professionals, in New Jersey the governor Phil Murphy put out a rather different call in his press conference on April 4, 2020, in which he said (comments lightly edited for clarity):

“Secondly in our list of volunteers not only do we need healthcare workers, but given the legacy systems we should add a page for COBOL computer skills, because that’s what we’re dealing with in these legacies. Chris Ryan is doing a heck of a job, but literally we have systems that are 40 plus years old. And there will be lots of post mortems and one of them on our list will be how the heck did we get here when we literally needed COBOL programmers?”

Without meaning to be crass, a lengthy post mortem is not needed to answer Governor Murphy’s question. The answer to that question has been known for more than 25 years. But that this answer is not readily known is a testament to our failure to learn from past disasters.

Granted, before providing that answer, it is worthwhile to say a little bit more about COBOL. In 1959 the Department of Defense brought together a committee and tasked them with developing a Common Business Oriented Language (hence COBOL), and once the specifications were made public several computer manufacturers adopted the language. While COBOL was hardly the only programming language in use at the time (FORTRAN was also quite popular), COBOL received a major boost when the US government declared that it would, from then on, only purchase or lease computers that could handle COBOL.

Perhaps the true significance of COBOL was not the government’s backing of it (or its association with the legendary programmer Grace Hopper), but that it was one of the first languages that was sufficiently standardized as to make it possible for the same program to run on machines from different companies. A further aspect of COBOL that enhanced its popularity was that, thanks to Hopper, the way the language was written bore a strong resemblance to regular English, meaning that the employees who used it could get by with less technical expertise. Though COBOL was born in 1959 and had its heyday in the 1960s, programs written in COBOL have had extremely long lifespans—with some of these systems (such as the unemployment program in New Jersey) still relying on this language today.

Granted, COBOL is hardly the freshest or hottest programming language. When people learn to program today it is quite likely that they will never learn COBOL. Indeed, even in the 1990s, COBOL was seen as a bygone language known only by the old-fogeys and dinosaurs.

Which brings us back to Governor Murphy’s question: “how the heck did we get here when we literally needed COBOL programmers?”

And here’s the answer: because we failed to learn the lessons from the year 2000 software crisis (better known as Y2K).

While many people may remember the apocalyptic predictions that surrounded Y2K, it was at core a relatively simple technical problem. The challenge posed by Y2K was not that the problem was particularly technically complex, but that it was so pervasive—the issue was really one of scale. At base the issue was that dates in computers had been programmed using six characters with the century characters being left out. Thus, August 14, 1958 had been written as 081458 with the computer assuming that the century was “19.” But when those last two characters were “00” all manner of hell could break loose if the computer assumed the year was 1900 instead of 2000. Many of those problems would be calculation errors (which could be quite serious for financial institutions), but some systems would simply shut down completely as a result of the rollover if nothing was done. Luckily, the problem was identified early by computer professionals, and thanks to the diligent (and unsung) labor of thousands upon thousands of individuals the problem was largely fixed before the deadline. Granted, the way that we remember Y2K has tended to focus on the warnings of all hell breaking loose, while failing to recognize that the fact that hell did not break loose is not because such warnings were fear-mongering nonsense, but because the needed preventative steps were taken.

To put it another way: if the experts warn “unless we do [x], terrible thing [y] will happen!” and enough people in positions of authority take those experts seriously and do [x] thereby preventing [y], it doesn’t mean that [y] was never going to happen. And that is a fine way of summarizing Y2K, even if the absence of major calamities has often been seen as proof that Y2K was a hoax, instead of seeing the lack of major calamities as proof that the all of the work that was done was ultimately effective.

But, to get back to Governor Murphy, what does this have to do with COBOL?

Simple, because one of the programming languages infested with the Millennium Bug was COBOL, and fixing Y2K demanded the expertise of legions of individuals with “COBOL computer skills.” Yet, even in the 1990s there were not enough properly trained programmers to do all of that work. Yes, already by the 1990s COBOL was a programming language that was seen as the provenance of dinosaurs. And one of the issues that exacerbated the Y2K crisis was that there was a shortage of COBOL programmers. Granted, in the 1990s many of them could still be summoned out of retirement with enticements of high pay, but today COBOL skills are becoming rarer and rarer. Of course, COBOL was hardly the only programming language that had Y2K related issues, but its presence in numerous legacy systems certainly helped to make it one of the major culprits in Y2K. The “Common” in COBOL should not be shrugged at, it really was (and to an extent remains) a very common language. Thus, one of the important ways in which Y2K answers Governor Murphy’s question is by demonstrating that it is not enough for your technical staff to be trained in the latest and hottest techniques, sometimes they still need to know those stuffy old programming languages.

Another applicable lesson, of equal importance, that should have been learned from Y2K, is that many companies and governments remain reliant on legacy systems—and many of those systems still run on old code. One of the questions that often gets asked about Y2K is “why didn’t early programmers use eight characters for dates, didn’t they know the year 2000 was coming?” It is a fair question, to which the answer is that most of those programmers were fully aware of that potential problem, but they could not conceive that the code they were writing in the 1960s would still be in use decades later, but it was. And, evidently, some of that old COBOL code is still in operation today. What’s more (at least in the case of the NJ unemployment system) it seems like a lot of those programs were still working fairly decently until this crisis came along. And before anyone laughs at this misfortune in New Jersey, it is worth bearing in mind that New Jersey is almost certainly not the only state (or company) that is still relying on legacy systems that are one crisis away from breaking down.

Most people remember little about Y2K beyond the hyperbolic headlines mocking doomsday preppers (while ignoring the calmer assessments that were being by computer professionals), and thus not much attention is usually paid to the actual work that went into fixing the problem. However, one of the first steps that companies/governments/individuals were instructed to take in preparing for Y2K was to conduct a thorough and comprehensive audit of all of the computer systems upon which they relied—paying particular attention to which systems were legacy systems, and what languages these various systems used. That information was then used to guide the triage plans regarding the priority with which certain systems were to be fixed. And in many cases the recommendation was not merely to fix these legacy systems, but to replace them with a newer system that would not present these problems in the future. Furthermore, one of the long term takeaways of that work was supposed to be that companies/governments/individuals would now have a clear understanding of the systems they were using. Indeed, in the post mortems of Y2K, one of the silver linings that many people pointed to is that the crisis had provided an excuse for companies/governments to get a firm grasp on the types of systems they used.

Evidently, that grasp was not too strong.

There are many different lessons to take from Y2K, and the lessons that you derive from the crisis will likely depend somewhat on the way you look at that crisis. For some, the lesson of Y2K is about the importance of listening to expert advice and acting upon it swiftly and seriously. For others, the lesson of Y2K is that societies expose themselves to new kinds of risks as they come to be heavily reliant on opaque technical systems. From one perspective, the lesson of Y2K is that it is particularly difficult to learn lessons from a disaster that was successfully prevented—as the prevention will lead many to conclude that the danger was never real. And, from a somewhat more banal perspective, one of the basic lessons of Y2K is that despite the high-tech gloss of our computer dominated society, many of the programs and systems we rely on are themselves still reliant on old programs and old programming languages. Indeed, at the most basic level, the lesson from Y2K is that you should be aware of the eccentricities of your essential programs before a crisis hits.

Therefore, that New Jersey is still using some systems that are “40 plus years old” is no surprise, that New Jersey is still relying on some “legacy” systems should catch no one off guard, and that some of these systems require programmers with “COBOL computer skills” is to be expected. Alas, what is hardly shocking, is the ways in which this unfortunate situation in New Jersey attests to a failure to learn from a past crisis.

So: “how the heck did we get here when we literally needed COBOL programmers?”

Simple, because we failed to learn the lessons from Y2K.

*

For more on how we should remember Y2K, check out: “The lessons of Y2K, 20 Years Later”

*

Related Content

An Island of Wisdom in the Cyberstream – on Joseph Weizenbaum

Riddled With Questions – on Interrogating Technology

When Technophiles Cry Troglodyte

Be Wary of Silicon Valley’s Guilty Conscience

From Megatechnic Bribe to Megatechnic Blackmail – on Lewis Mumford’s legacy

About Z.M.L

“I do not believe that things will turn out well, but the idea that they might is of decisive importance.” – Max Horkheimer librarianshipwreck.wordpress.com @libshipwreck

View all posts by Z.M.L →