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

Why not?

[__aaclcg7560]

Java is getting long in the tooth. Time for it to become the new COBOL.

Re:Why not?

[Slicker]

Java is far more likely to go the way of the dodo bird than is COBOL. COBOL is well-optimized for business data processing. It's a fine language. What does Java have over it? COBOL is many multitudes easier to learn, code with, read, and modify. Programming languages started getting more complex, harder to learn, and use starting with C++. And OO design and programming has failed in each and every goal for which it was originally proposed. I understand that most modern programmers have learned OO from the start and have difficulty thinking of problems differently but contemporary COBOL supports OO, too... just not often used.

Re: Why not?

[Anonymous Coward]

Cobol is a horrible business language. Unicode? No. Variable sized data fields! no.. Threads? No. Useful libraries? No. Integration with other components? No.

Just because it can add and subtract doesn't make it great.

It just makes it basic.

Re: Why not?

[Anonymous Coward]

COHBOL? Common Horrible Businness Oriented Language?

You're wrong about integration. On the legacy platforms that we're going to be interested in there was and is excellent inmtegration. I used to work on Data General and know that Cobol supported a number of DGs proprietry databases including heirarchical and relational.

The context here is about maintaining old s/w verses replacing with new. Sure if you're prepared for ironing out all the issues with you're new s/w then go for it but the s/w here is reliable and still basically useful, it just needs maintenance.

I've seen organisations replace old but good s/w with new s/w tht did the same job but was 'modern' and had more issues, it needed more resources and ultimately did no better a job.

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

[maglor_83]

Referring to banks, not delivery drivers. The delivery company would use vans because it's far more efficient (ie cheaper). The bank would train COBOL devs because it's also much much cheaper than replacing a working system.

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

[RightwingNutjob]

All programming languages are tedious as fuck to use. In fact, work itself is tedious as fuck when the alternative is beer, sex and video games. Yet people still go to work because they get paid money for it.

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.

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.

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

Automatic Conversion

[crow]

It's been a while since I've touched COBOL, but it should be possible to develop a program that parses COBOL and outputs the equivalent in a modern language, even preserving the comments.

Since financial institutions seem to be completely unaware that programmers can quickly adapt to different languages, it would seem like an automatic conversion program could be quite profitable.

Re:Hopper who?

[dbIII]

why wouldn't we include her full name?

Because mentioning a woman in IT triggers far too many snowflakes who will moan about how it's manly men's work to sit inside an office and type on a keyboard - no place for women at all.