Is history doomed to repeat itself? Or rather, is there really any doubt that it isn’t, considering recent events that made the news? I am of course talking about New Jersey’s call for COBOL programmers to fix their ancient unemployment system, collapsing under the application spikes caused by the COVID-19 lockdown. Soon after, other states joined in, and it becomes painfully apparent that we have learned absolutely nothing from Y2K: we still rely on the same old antiques running our infrastructure, and we still think people want to voluntarily write COBOL.
Or maybe they do? Following the calls for aid, things went strangely intense. IBM announced to offer free COBOL trainings and launched a forum where programmers can plug their skills and availability. The Open Mainframe Project’s COBOL programming course suddenly tops the list of trending GitHub projects, and Google Trends shows a massive peak for COBOL as well. COBOL is seemingly on its way to be one of the hottest languages of 2020, and it feels like it’s only a matter of time until we see some MicroCOBOL running on a Teensy.
However, the unemployment systems in question are unfortunately only a tiny selection of systems relying on decades old software, written in a language that went out of fashion a long time ago, which makes it difficult to find programmers in today’s times. Why is that?
In the end, COBOL is “just another language”, regardless of its age, and nothing stops anyone from learning it or developing with it. Just because it’s an old language doesn’t mean COBOL is entirely outdated and irrelevant either. Computer languages don’t “die”, they just go to sleep.
Or in the case of COBOL, it’s more that the areas where it makes sense to use the language are limited and highly specific. COBOL’s natural domain is reliable high volume data processing and it’s a perfect language for that use. COBOL is solely outdated as a general-purpose language.
So maybe the issue of finding COBOL programmers isn’t really about the language, but rather what its use implies about the systems using it, and the work environment one can expect. The thing is, those systems are a product of their times, where development processes and methodologies as we know them today simply didn’t exist, embedded in industries where software is merely seen as a tool, if not a nuisance. But COBOL itself is irrelevant here, we’d be in the same situation with any other language. Worse yet, if we don’t start to finally tackle the actual issues at hand, or at least learn from them, and continue to blame everything on an old language, history is going to repeat itself, and we will end up in this exact situation with other languages as well.
But what issues am I talking about then? Well, let’s start from the very beginning, and the lack of love for COBOL.
An Ode To COBOL
While virtually everyone has heard of COBOL in one way or another, and stating that someone you know has once worked with it gets you some serious street cred, the language doesn’t really get much attention here on Hackaday. If it wasn’t for honoring the life and works of those involved in its earliest development and paving the way for it, we’d barely see anything at all about it. But it shouldn’t really come as a surprise either, after all it is the Common Business-Oriented Language. Could a name be more hacker repellent? And unlike with BASIC, nostalgia won’t be of much help either, considering its main application areas.
As a result, COBOL has a sour side taste as a boring language that requires you to bring a tie and a broom stick to work. Nevertheless, COBOL is a definite and important part of computer history, and as we can see from the recent news, still plays a big role 61 years after the initial meeting that kicked off its existence. Depending where we look at, it might even be the dominating language in its field.
As rule of thumb, the more disastrous a system failure could be to society, the more likely it is to find COBOL in it, with banking usually serving as prime example, along with insurance, health sector, civil infrastructure, and of course government administration such as the aforementioned unemployment systems. Looking at some numbers, 43% of all banking systems, 80% of point-of-sale, and 95% of ATM transactions in the US used and relied on COBOL code in 2017, and it won’t be much different when we look at other countries.
So all in all, programming in COBOL gets you to work in incredibly sexy environments that can easily keep up with the excitement and coolness of, say, game or web development — not.
The Generation Conflict
Yes, yes, not everyone cares about that or wants to do gimmicky web or game development, apart from those spoiled youngsters who don’t even know how to change a register value with a screwdriver anymore — but that’s kinda the point. Every time a COBOL shortage is mentioned, the main issue seems that the old generation that knew the language has left the active workforce. Meanwhile, we advanced an entire generation since Y2K, and it’s still the same issue all over again. Yet those born during the last big COBOL crisis are now slowly entering the job market as new developers, in higher numbers than ever before, and their mindset, skills, and interests couldn’t be further away from the language and the systems using it.
And why would it? Software development and the opportunities within it is nothing like it was in the 90’s, not to mention the 60’s. Keep in mind we’re talking about a generation where the computer isn’t a miraculous wonder device, but a commodity. What was revolutionary once, has become a bare minimum at best.
But attractiveness and generational differences of interests and fascinations are really just the seagull sitting on top the tip of the iceberg. And no, compulsory COBOL courses in elementary school won’t be the solution. Plus, it’s not like you couldn’t run COBOL from Node.js or the other way around to cater to those youngster web developers.
On the other hand, different strokes for different folks and all, so the business field or its attractiveness might not necessarily be a problem. I mean, who am I to question people’s preferences, and developing for mainframes can definitely sound thrilling. But here’s the thing: these urgent calls for COBOL programmers only ever appear when there’s a crisis to be averted, so you’ll likely just end up as a code janitor whose usefulness ends as soon as the job is done. In other words: lack of job security as a blessing in disguise, since your work is likely going to be frustratingly dull and uninspiring anyway.
That leaves the people who either don’t care about any of this, and those who counter the job security situation by publicly claiming how they’ll do the job for a 2+ year full-time contract at $400 an hour and a complementary banana. In a way, they have a point, but the first group is definitely going to win that bidding. Why? Because this generational mismatch of values, interests, and expectations goes both ways, and we’re talking about industries that, for the most part, aren’t native to software development.
A Revealing Number
Let’s take another look at those numbers from earlier and focus on the one I didn’t mention yet: 220 billion lines of code in existence. Pick any random article about COBOL, and it’s guaranteed you will find this same number (±20 billion, depending on the year), presumably to impress by demonstrating how omnipresent the language and the systems its running on are.
Does it though? Or does it rather expose the zeitgeist of the industries where COBOL is actually in use, and the dissociation between today’s software world and those crying out for its help? Which would imply that this is an issue of obsolescence after all, but it’s still not the language, but the way software is perceived.
I mean, when was the last time lines of code had any relevance for software developers, or even their supervisors, especially where more was better? If anything, people pride themselves nowadays how few lines it took them to solve a common problem. Think of the millions of hours wasted in flame wars that could have been saved by simply showing how Linux’s ~50 million lines makes it clearly superior to FreeBSD’s puny ~25 million lines, and why OpenBSD still beats them all. (By this metric, Emacs would beat Vim, hence proving my point that lines of codes are clearly meaningless.)
But alright, maybe that number is just meant as a fun fact and I’m seriously overinterpreting it. Then again, maybe I’m not, and it really provides some unintended insight on what to expect in a COBOL work environment, where software development is seen as mere manual labour, like punching metal sheets in a factory. Don’t forget to add your words-per-minute count to your CV.
Anyway, that’s still not the whole story. Let’s talk about the code, then.
Ghosts In The Machine
How often do you look at someone else’s code and become convinced you could have done it better? And how often did you have to deal with legacy code and curse its author? If you’re lucky, you can just refactor it and move on with your life. If not, you might realize halfway through that everything has happened for a reason, despite how weird it looks, and you eventually find a less elegant way to work around it, introducing new peculiar code the next person may find questionable.
Now imagine that was the norm. Not only that, but imagine how decades and decades of workaround after workaround piling up in the codebase has become the very core of the system itself. No doubt, every single patch had its reason and validity to exist, and whoever wrote it surely knew what they were doing. Maybe even the next person working on it, adding their own workarounds, has been around long enough to remember everything about some specific quirk that had to be handled carefully. But that was ten iterations and 30 years ago. The original business has been acquired twice and restructured thrice since then, and each time it was integrated patched together with another system that has grown the exact same way.
Remember that we are talking about systems that are critical to our infrastructure. Their undisrupted operation is crucial, and some decades ago, you couldn’t just try out a few solutions on your commute to the office and run some automated tests during lunch. Whatever did the job had to be good enough, and we know very well that nothing is more permanent than a temporary solution that works. Considering that Y2K became an issue in the first place, people clearly didn’t expect that those systems remain relevent for decades to come.
Well, they did, and the point of no return was passed long ago. Mix in the mentality towards software and the replaceability of programmers, and things could have only gotten exponentially worse since. If Y2K was a problem because the people that initially developed the system had left the workforce, what can we expect a generation later, when those who had to painstakingly figure out all the quirks to add new workarounds themselves are retiring as well?
But once again, this has nothing to do with COBOL, and throwing COBOL courses at people won’t be a silver bullet. If anything, it takes a frustration-resistant mindset, perseverance, and a high pain threshold to dig through the code — something you can’t teach, and repeating the same old “we need COBOL programmers!” chants will hardly increase the number or availability of people with those abilities. Sure, it requires COBOL skills to fix the system, but COBOL skills alone won’t get you far.
Towards A Brighter Tomorrow
So what is the solution then? I hope it’s obvious enough that the problem is too complex in its entirety to have a single solution, and each aspect I mentioned, which I’m sure doesn’t even cover half of the entire picture, will require separate considerations.
One thing is sure, handwringing in hindsight that everything should have been handled differently back in the 60’s or 90’s won’t cut it, and neither will writing everything from scratch. Getting there little by little is probably a good start, but the complexity that makes the codebase a problem in the first place won’t be fixed this way. If anything, it risks complicating things even more because it requires to fully analyze and understand every little detail and quirk, with zero room for errors or guesswork. It will take years and years of planning, and who is willing to invest that time and money when the majority of systems seem to work “just fine” right now?
As for the other issues, well, you cannot change people. But you can try to understand them — which goes both ways. Yes, the current generation makes software engineering probably one of the most spoiled professions ever, but just because you had it worse and didn’t whine doesn’t mean everyone else is willing to go through that themselves — just like technological basics and their history that seem obsolete in practice are still valuable and worth knowing.
We do live in a different age than the systems that are running COBOL. The ubiquitousness that software has reached doesn’t only provide entirely new and exciting work areas, but hopefully shows that it’s more than just a cost factor to those that have otherwise no direct relation to the field. And if not, then let’s at least take a lesson from it for ourselves. We can hardly blame the developers or their supervisors who didn’t know better at the time for this situation, but if we don’t start to finally learn from it, next time is definitely going to be on us. And that applies to areas both outside and inside the R&D departments.
Unlike 60 or even 20 years ago, we have a plethora of tools at our disposal today that allow us to track changes, progress, issues, and requirements in our software, most predominantly in form of issue tracking and version control. But none of that has any use with a halfhearted adaption for the sake of just having it done, and "fixed stuff." commit messages — and don’t even get me started on code documentation! The way we look at software development may have changed from 60 years ago, but we still have a long way ahead to adjust our mindset until we stop making the same mistakes all over again.
Well, at least next time the crisis will involve some more common languages, and everyone fixing this year’s unemployment systems can hopefully retire in peace by then. And I’m convinced, the headlines won’t call for Pascal or C developers then, so maybe we can finally stop pretending this is all a COBOL issue, when it’s really a “dreadful work expectation” issue.
On a final note, I’d be thrilled to hear stories from the trenches of those who were involved in preventing Y2K at the time!
No comments:
Post a Comment