Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com)

COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

Comments

COBOL isn't hard to learn

[Anonymous Coward]

COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.

Whoever wrote this article unfortunately appears to subscribe to some bizarre employer-centric view that programmers and CS grads are not allowed to learn programming languages on-the-job. COBOL-coded systems are for back-end processing, not for customer-facing systems.

Re:COBOL isn't hard to learn

[Kjella]

Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.

As long as you have a real fall-back so your career doesn't dead end. What can easily happen is that you do X then more of X because it's the only place you get a salary/career development until you've done X so long nobody will really hire you for anything else. I see this with for example some SAP consultants, essentially SAP customers want to hire you for your SAP experience and the rest of the world doesn't care that you have a general IT degree 5 or 10 years ago because your experience is all SAP-specific and they don't run SAP.

Now they're probably safe since that ERP is burrowed so deep into many companies they'll never get out, but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position. That is if they'll even hire you or if they'd rather have a recent college graduate. Or you might have to relocate to find one of those increasingly rare positions that actually value your COBOL experience, which of course only makes it harder at the next crossroads.

If you write cell phone apps as a hobby and can show them a portfolio or something, maybe you'll get away with it. No, you're not a dinosaur who only knows an outdated language and best practices from 50 years ago. Or some other way to be able to transition away from that COBOL career more smoothly. Some of my older colleagues noted that the parking inspector at work used to be COBOL programmer some 20 years ago, they updated their skillset and apparently he didn't.

Re:COBOL isn't hard to learn

[Strider-]

Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates.

Oh, hell no. Universities and computer science departments are not trade schools, and we shouldn't be expecting them to teach any specific technology or language. That is not what the discipline is about. What they should be doing is producing graduates that grok and push the concepts that underlie computing in general. They should have a good grasp of algorithms, object oriented design, logic, and so forth. The language is incidental. A well educated grad should be able to pretty much pick up any language, and view it as simply another syntax, potentially with slightly different grammar. In practical terms, a good CS program is far closer to being an applied discrete mathematics degree, rather than a programming degree.

Re:COBOL isn't hard to learn

[Anonymous Coward]

I went to community college and we had an Associate's track in, basically, mainframe computing. AS/400, JCL, COBOL because we had several local firms that still maintained and ran mainframes (and last I checked, still do. I believe one tried to move to commodity hardware and rewriting the whole stack in Java, but I don't know if they finished that transition).

The problem with "just picking up COBOL" isn't necessarily the language, it's the whole system it's deployed on. There's no CLI that a Linux user would readily recognize (I found it easier to think of it like a BBS), the whole Jobs system is utterly alien to someone used to VAX/UNIX, etc etc. My local college also did a lot of that, but in the MIS department. The EE department started everyone out on VAX/VMS and Pascal, the CS department on C and qedit. :D They moved to Visual Studio not long after, though.

Re:COBOL isn't hard to learn

[Altrag]

I agree the article's claim is dumb, but not for the reason you suggest. Finding programmers is easy (at least if you're willing to pay a reasonable wage,) and teaching them COBOL is easy as well (any decent programmer should be able to pick up a new language within a week or two.. especially if they're hitting the ground running and have no choice but to learn it.)

The problem is the business logic. Banking isn't particularly simple at the best of times, and all of those ancient systems will have decades worth of hacks built on top of the base logic for whatever corner cases, hardware workarounds and other tweaks that have been needed over the years. A new programmer learning COBOL will have to be wary of those kind of hacks until they understand them. A programmer trying to port the system to another language/system on the other hand will have to understand those hacks all (nearly) at once in order to make sure they properly get replicated.

I don't really see any reason beyond simply "new is better!" to do this. By the time they manage to fully port and test the new system, they'll be wanting to rewrite it again in the next fad-language-of-the-day. I mean name one "top" language today that's been around for more than about 5 years and doesn't already have people crowing about how its past its expiry date and everyone should be rewriting all their code in some other language. There's the occasional specific domain where that happens (C++ for performance-centric applications like games, Fortran for sciency things, Matlab for mathy things and the such) but anything even close to general purpose? Few if any.

Re:COBOL isn't hard to learn

[vtcodger]

Once, many, many years ago, I had to look at some COBOL software to see how it was handling some data. Remarkably easy to read and I'd never seen the language before or since.

I don't think I'd have the patience to program in COBOL

But I have to say that if I were an IT manager responsible for hundreds of thousands of lines of that stuff that worked, I'd probably be REALLY reticent to scrap it in favor of something more "modern".

Re:COBOL isn't hard to learn

[rickb928]

COBOL was ubiquitous in the financial industry before SAP's predecessor was someone's dream. COBOL will take 10 years to get rid of *if* all users begin concerted efforts to do so, these transaction processing systems are too important to just 'replace' without careful planning, development, and most importantly defend against feature creep and being engineered into failure.

SAP is a baby. COBOL is grand dad. And grand dad still gets out of bed, does his work, and does it well. There is indeed a market for fresh COBOL programmers, and a decade before they need to move on to a new platform.

In a world where we are cautioned that we will have multiple careers as the job markets change and adapt, it's ludicrous to pretend that programmers can't move on to new languages, new platforms, new challenges. What is being said is "it's cheaper to hire new grads than to hire retrained experienced workers". That is sharp practice. Not nice, but profitable. And not new.

Re:COBOL isn't hard to learn

[clintp]

COBOL isn't hard to learn, and it can be understood/read/debugged a lot easier than many of the more contemporary languages. Banks that want to maintain COBOL systems need to just hire new CS graduates and give them time to come up to speed on the COBOL language.

All this may be true but why would they do that when, if they replaced it with something developed in the current century, they would not need to. A delivery company could train it's employees to drive horses and then use horse carts to make local delivery runs but why would they? Well perhaps for a sales gimick but otherwise using old technology often gives significant disadvantages beyond the need to train your employees.

I've worked in legacy software for a long time... and here's the thing.

Those COBOL systems aren't off-the-shelf modern framework-driven standard software packages. These packages were custom-built and tailored to the business needs of *that particular institution* over many years. You can't plonk down a credit card and buy a replacement; there's no github repository for that kind of code; you can't knock one out in a couple of weekends in a code camp.

That business' processes have co-evolved with that software for better or worse. Replacing it means rebuilding it around the existing business.

The programmers that work with this old cruft know the ins-and-outs of the system -- and if they're smart, they've learned the business, and the business owners *know* they know it. When the business decides to replace it, that's when the developer steps up and says "I'll do it, here's the plan." You go in as Jr. Programmer, you come out as Sr. Software Engineer.

In 30 years I've written (whole or in part) 2 payroll systems, 1 full-financial system (AP, AR, GL, etc..), 1 room scheduling systems, one freight routing system and one tax filing system. Each one (for its time) very modern, but based on older shittier systems that had to be learned and maintained before that.

Re:COBOL isn't hard to learn

[Anonymous Coward]

Even if students coming out of a course should grok code in general, that doesn't mean they have discipline-specific skills in COBOL necessary to allow them to deal with this kind of code. Some of that stuff is learned over decades.

It's entirely the bank's fault for not taking on young employees and teaching them these new skills, and putting them with the veteran programmers and guaranteeing their jobs for life, with good pay and conditions. They have no one else to blame.

Had they done this, it wouldn't be a problem. COBOL would just be the language that banks use - nothing else. Banks seem to feel it's the universities responsibility to churn out skills that they might want some day, but without paying either the universities or the graduates ( through employment ) for their services.

They still have time for this - all they need to do is pay enormous amounts to programmers willing to sit with and replace aging veterans. Good luck to them. I hope the banks choke on this.

When I studied, we were forced to learn COBOL for precisely this reason. No one was ever hired, or taken on, or otherwise employed out of it - It was just one of those "Industry want this, so we're teaching this" situations, but the truth is that industry only ever want experienced programmers, but they want them to gain that experience somewhere else.

When we see COBOL programmers paid 1 million per year, like high-flying executives, we'll know they finally realized their value. In the mean time, maybe a few more executives should be prosecuted when they have losses due to COBOL bugs and failures, for running systems they refused to maintain, with foreseeable outcomes.

Re:COBOL isn't hard to learn

[arglebargle_xiv]

Exactly, if there's a demand for it, it'll be fulfilled. The article reads like something written by some recent CS grad, lets throw out this horribly uncool, unhip code that nevertheless can handle three trillion dollars of transactions a day and has been going for forty years and replace it with something that some Indian subcontractors slapped together using Ruby and MongoDB.

In a past life I worked for a bank. They decided to replace their existing Cobol on IBM big iron with Java on... something that wasn't big iron. After several years work and tens of millions of dollars spent and even more than that lost due to problems with the new, modern replacement systems, they threw in the towel and made their modern system screen-scraped 3270s because that shit just works, and keeps on working. It's now all Windows-based at the front end, but everything in the backend is still Cobol on mainframes.

Re:COBOL isn't hard to learn

[Z00L00K]

SAP is more likely to go the way of the dinosaurs than Cobol.

Which reminds me of this joke:

In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.

A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.

Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.

Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.

They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."

"Someone like me?"

"You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."

"What year is it now?"

"Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"

Re:COBOL isn't hard to learn

[goose-incarnated]

but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position.

You think that a systems migration won't need your legacy skills? You think that you won't pick up the skills for the new system during the migration?

Here's a more likely scenario: you do COBOL for 5 years and learn the entire problem domain that the COBOL system services. When the migration occurs with Java your knowledge will be indispensable, and you'll no doubt learn Java in the two years the migration takes to complete. At the end of the migration, you are still the expert in the problem and have new Java skills to apply your expertise.

It's exceptionally unlikely that the migration from COBOL will be so fast that you won't be able to learn the new implementation technology.

No.

[xxxJonBoyxxx]

>> Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.

Er...that's pretty much been the story since the 1990's (if not earlier) on.

>> mostly maintained by retired programming veterans

Er...if they're "maintaining" then they aren't "retired". This whole article sounds companies that whine about not being able to find skilled welders, etc. Well, open your wallet and the talent will materialize - see "IT security" for an example.

How about a 4th option ?

[psergiu]

How about a 4th option ?

Fscking pay to train people. If COBOL knowledge means means a good paycheck and job stability - lots of people will want to do that.

I mean hydroponics and grow lights are all the rage now but i hear of no plans of migrating all the existing old-style dirt-based and sun-lighted vegetable gardens to that. Why ? Because people are still learning how to dig the dirt out in the sun.

It will probably never die

[El Cubano]

Having spent quite a bit of time over the last two years to re-implement in Java a system developed by the government in COBOL, I can tell you that COBOL will probably never die. For example, keeping precise, penny-perfect calculations of dollar amounts in Java is actually quite a pain. This is especially true when the calculations involve dozens of hundreds of steps. My solution in Java has been based around BigDecimal, which makes the code very difficult to read. Aside from that, I have spent the vast majority of the time writing very extensive tests and chasing down really small numeric discrepancies. Guess what, if you decide to replace a COBOL system that does any appreciable amount of math, you would get to do the same thing. Plus, you will never be sure that you found all the bugs.

The project actually considered the possibility of licensing a commercial Cobol runtime for PC-based platforms (e.g., Windows, Linux, etc.), but that was not feasible for several reasons.

COBOL is still remarkably good at quite a few things and leaves out lots of the bells and whistles that tend to become distractions in the hands of undisciplined programmers. My only complaint about COBOL (especially old COBOL) is that the control flow is a real pain. Aside from that, it is definitely a workhorse of a language. No need to go killing it off yet.

So train the next generation of COBOL programmers

[srstites]

The article does not mention what I consider to be the most obvious solution to the problem of old COBOL programmers dying off. Businesses with a COBOL maintenance problem should train young people how to program in COBOL. The businesses will need such people even if they plan to convert their code base to a different language as such a conversion would take years to implement.. --------- Steve Stites

Or use in-house education

[isj]

2 years ago in one of the banking centers in Denmark 12 new IT-candidate were educated in ... COBOL, CICS, mainframes, etc. The older generation were anxious about how the younglings adapt, but it appears it turned out well. They were excited about the robustness and scalability of the mainframes, not so much about COBOL, but could see it didn't make business sense to rewrite old software. New software is being developed in more modern programming languages.

source (Danish only): https://www.version2.dk/artike...

Re:BUGS

[Anonymous Coward]

COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.

Said the person with very little knowledge of modern COBOL environments !

I'll grant that COBOL is not like PL/I, where 80% of the programmers know = 20% of the language.

However, COBOL has one of the richest I/O layers (ok, on par with PL/I) around.

Caveat Emptor - I intensely dislike the language (to damned verbose), but it and PL/I do pay fund my paycheck (just call me 'Dinosour Bob').
But the COBOL I learned was circa 1970s, when even COMPUTE was frowned upon (in school) ... And Databases where not yet relational !

Modern COBOL has OO patterns, JNI integration, XML/JSON tooling, ... All to deal with the option of:
    * Keep the business logic in COBOL
    * Provide the ability to work with newer toolchains (Java, XML, JSON, ...)
So there is interoperability betwixt the green-screen and non-green-screen luser.

Re: What is needed..

[techno-vampire]

Cobal is a crazy nuanced language that is hardware specific.

Absolutely wrong. One of the language's biggest selling point when it was first created is the source code is completely hardware agnostic. To demonstrate this, the developers compiled the same program (from the same deck of punched cards) on three different brands of computer, ran the program with the same deck of input data and got the exact same results. The only change they had to make was one card in the Environment Section, and all that card did was specify the target machine.

Re:What is needed..

[msauve]

What's obviously needed is a COBOL -> APL translator to convert all those programs into a newer language.

Re:What is needed..

[CaseCrash]

I couple of years ago I worked at a place that has an automatic converter from COBOL to C#/VB.Net (followed by an insane amount of testing and fixes to the converter/custom fixes for their code) and we handled all kinds of businesses including banks (I got to spend three weeks in Belgium helping out on the ING project). So people are already doing this.

(FYI, the company is Asysco)

Just pay enough.

[dpbsmith]

I remember this coming came up during the Y2K flap. COBOL programmers are dying out because companies have decided, for whatever reason, that they aren't willing to pay them much. A quick Google search--I don't know how reliable--shows me:
COBOL Sr. Software Engineer / Developer / Programmer $88,049
Java Sr. Software Engineer / Developer / Programmer $103,239
But that understates the difference because the various job titles shown for COBOL positions are predominantly lower-sounding and lower-paid positions.
As several have said, COBOL isn't hard to learn--I don't know it but I crammed it once for a test. Like all languages it takes a while to get good at it, but it's not specially difficult, nor is it specially bad.

The best strategy would be to render unto COBOL what is COBOL's--keep good legacy systems in COBOL--and pay enough to give people a reason to learn the language.

Re: Why not?

[slack_justyb]

Holy shit dude. I'm a vet C++ programmer and the last three years mobile developer for warehousing company. However about a year before my current job, I worked in an exclusive AS400 shop. RPGLE, COBOL, CL, you name, it was still using the stuff from back in the day.

The system was incredibly fragile and had insanely complicated builds with the labyrinth of binding directories, dependencies, the constant service program signature violations. Customers demanded new functionality and the system just had trouble keeping up. Old programmers would code crap like RPG still lacked arrays with abusing subfiles. They'd swear by using numeric indicators versus the new fancy types. Yeah, because IN73 being on tells me that I totally need to refresh the data on the screen. Eventually the company fired all of the RPG/COBOL programmers because they could never keep up with demand. They were short order replaced by an off the shelf solution and any new work was contacted out. I stayed on a few months more because I understood EDI and they needed someone to get that all setup on the new solution. Oh and it was Java based.

Point though, you sound exactly like those old guys. OO over complicates crap and you don't need all that fancy stuff, blah blah blah. I work and coded DDS, SQL, RPG, and COBOL with those people for five years and I knew their mentality was just setting them up for obsolescence.

The tech industry is brutal man and you've got to be a person keenly adept to rapidly adapt or you'll find yourself quickly no longer employed and lacking serious skills to find your next job. Two, besides myself, out of our group of nine found another job. Those two for jobs doing AS400 maintenance, took a pay cut for it, and RPGLE programmer with the State Government, smaller hit to the paycheck than the first guy. The rest of the group have nothing but their retirement savings to dip into. We all lost touch over the years but last I heard two or three more for jobs finally but had to eat the cost of moving elsewhere.

Seriously, the only thing that kept me above water was that I had skills in C++ and Java. And since then I've picked up containers with Linux and node.js plus Python and some big data (Hadoop and shit) just to what I assume is stay current.

That thinking of yours isn't a good kind in this industry. But I get it, when I worked with the AS400 folk, I had just turned 30 and so I was seen as the young whipper snapper etc. I had just left my last job of several years doing C++ and every gray beard (literally) there thought I was there to "think outside the box" and "shift paradigms" and really I was just there to mostly get a paycheck. Learning RPGLE and COBOL was fun but man those old guys they scoffed at any suggestion to get off a green screen or to make their monolith more modular. They would literally say, "stupid hipster just trying to make everything harder than it needs to be." And let me tell you, I didn't dress like a hipster.

Anyway, I know, way more memory lane than anyone asked for, but seriously, those guys' thinking ultimately led to their firing. I've worked in a few development teams but not a lot so can't say with a lot of experience, but my gut tells me that had they been just a wee more open to change and newer technologies, they might still be working at that place.