Governor of New Jersey Publicly Calling for COBOL Programmers

While the COVID-19 threats in USA not decreasing, lots of parts of public infrastructure are put into a test of pressure. Healthcare and unemployment systems’ infrastructures are two of them. Some of them are performing perfectly under the pressure while some are just failing.

One of the failing systems is NJ’s unemployment system. Last weekend, governor Phil Murphy publicly called out COBOL programmers to scale up their system. However, I’m arguing that the governor misunderstood the whole thing and turned people against COBOL for no valid reason.

What is COBOL?

A piece of COBOL code

COBOL(Common Business-Oriented Language) is a programming language developed by leading software engineers from universities, industry, and government of the time. It was 1959. Yes, this is a 61-year-old programming language. And also, the language is not deserted. COBOL is supported by the Microsoft at the year 2001 by adding COBOL compiler at the .Net compiler at the year. From that moment, COBOL is supporting .Net Framework components and object-oriented programming.

Despite of its age, COBOL is widely used in the US banks. A 2017 article of Reuters point out that estimated $3 Trillion daily flows through COBOL systems. COBOL was competing with FORTRAN in 50s, BASIC in 60s, C in 70s. Eventually, it find its niche and perfected itself.

Why the governor is mistaken(Why it cannot be COBOL)?

I believe the governor is mistaken by pointing out legacy code written in COBOL. In most cases, faults that are pushed to poor COBOL was about poor documentation or outdated infrastructure. In the same speech, governor mentions that their system is 40-something years old, which is empowering my point.

Why it could be the documentation?

That’s what it feels like to find something in shitty documentation

Documentation is not the IT industry’s strongest thing. And believe me when I say it was far worse back in 80s, where the NJ unemployment system is built. At that years, software is not something to be bought like today. Companies most of the time end up buying a whole system, including both computers, infrastructure and programs. So, the documentation from that years is mostly system oriented, which makes it hard to maintain the program. If the program’s documentation is not enlargened by years, state of NJ may have ended up with a garbage that is no pointers to how to fix it.

Why it could be the poor infrastructure?

In the IT industry, we all have the common instinct of “If it ain’t broke, don’t try to fix it.”. This could be the root cause of this problem. We all encounter outdated legacy systems that do not need any fixing cannot be fixed when it encounters a problem after a while. However, the government agencies should feel obligated to keep their systems relatively up-to-date. Think about this, if the agency even upgraded their system to the language C, which could be done probably 30 years ago, the support they can get from the IT community would be huge.

But should government agencies jump into hype trains?

Absolutely not. But staying in COBOL is a different issue. COBOL programmers are hard to find for nearly 20 years. The TIOBE index value for COBOL was 1.6% at 2001. The same year, C achieved 20.2%. C is still at the top spaces for 20 years while COBOL is now at 0.45% of TIOBE score, standing at the place of 29. I’m not saying that serious systems should hop into hype trains, I’m saying that they should hop out of the trains that are that low of passengers.

What could be the ad-hoc solution to this?

But these are all long-term solutions. How could state of NJ can rescue today? I believe the answer lies in open-source. I think state officials open their code to the community, asking for help. Seeking help with a physical appearance at the IT office is both outdated, and not possible in the conditions that we are in. Nobody will go to the mainframe at the state building to fix this broken system under a pandemic threat. After we survived this diminishing times, the state can build a new system in their discrete ways again.

What could be the way to prevent this ever happenning again?

1- Spend time on your working systems. Try to keep them up-to-date at least relatively. A 40-something year old system is not appealing. You should renew or renovate your systems at least once in a decade. I know that downtime or bugs during an update even once in 10 years is a crucial issue at these systems. But it definitely is better than this.

2- Listen to the industry. If everyone else is adapting different approaches, at least consider adapting it. Consider this, even if they don’t want to change all the understanding of their mainframe code, this could what state of NJ can do just by moving to languages that has previous language as a predecessor.

  • 1980: A COBOL mainframe is constructed.
  • 1990s: The mainframe is upgraded to Turbo Pascal, which is a predecessor of Pascal, that have the same file inclusion technique with COBOL.
  • 2000s: The mainframe is upgraded to Borland Delphi, which is a predecessor of Turbo Pascal
  • 2010s: The mainframe is upgraded to either C#, or C++ since C# is a predecessor of delphi and borland also sells a C++ compiler.

Guess what? C++ is at the place of 4, and C# is at 5 in the TIOBE index.

Tough titties, state of NJ, that’s a huge train to miss. I would help to both a C++ and a C# project at github. LOL.

See you guys around, have a good day!

Here’s the TIOBE index if you’re interested: HERE

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *