Glad to see someone else pointing this out.

The problem with these systems is that they are very old, and thus do not benefit from many of the more modern developments in the field nor do many quality developers learn the language.

The benefit with these systems, though, is that they are very old. With that age comes completeness. They're battle hardened, thoroughly tested, and a known quantity within the institutions that leverage them.

History is littered with companies that attempted to replace the core of their business with one big project written with newer technology, only to fail catastrophically.

During my first gig with a bank, I was appalled to see the ancient technology in play at the heart of the bank's systems, and the retired developers coming in part time on schedules they set for outrageous hourly rates to do maintenance tasks on that system. Over time, though, I came to realize that this was the most reliable and cost effective solution the bank had available.

The third option listed is what I see happening, but at a much slower pace than the article suggests:

> Basically, Döderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems. However, the key thing is how the connection to the old system is made. > Gradually banks will be able to address each and every product need that they have with new platforms that will replace the overly complicated COBOL add-ons. This compartmentalizes the banks’ COBOL-problem and makes it cheaper to fix, as it won’t have to be done all at once.

It's a glacial pace, but it's being attempted. The heart of the old systems, though, were still untouched last I had visibility into those inner workings.

You're correct on all points in my experience. My previous contracting gig involved writing Windows Server based code for a UK mortgage lender that interfaced between the internet based Hometrack valuation service, and a Fujitsu ICL clone mainframe running the core Cobol system for the lender. The key point about that system is that it is the core ledger for all the mortgage accounts, which add up to many billions. It's the golden record of all the mortgage accounts and payments. Replacing it with a new buggy system based on the latest tech could kill the business.

> The benefit with these systems, though, is that they are very old.

See, https://en.m.wikipedia.org/wiki/Lindy_effect

True, but as you admitted, everything is "a known quantity", i.e. more or less frozen.

Which is cool when everything works and nothing has to change. When something breaks or you need to change something... you wish you had things such as clean code, unit tests or even TDD/BDD, code coverage, continuous integration.

Banks are basically sitting on systems they don't fully control. They're kind of an interesting experiment: how long can you control the dragon, i.e. continue operating via patchwork and outside contractors which are in their 60s? :)

Small businesses are doing this as well (where I learned COBOL). Having experienced it, I do not feel there's really anything wrong with COBOL itself. The language is verbose and relatively straightforward, however it requires a different approach from what most people are used to.

Is it true that just for knowing the language you are getting compensated much better? How easy is the job market?

It might not always be the case. Hiring young people and teaching them Cobol (or whatever) without paying large amounts upfront might be also a viable business practice, ie. think about it as an entry level job. All depends on requirements, clients, etc.

This is how I learned. The team I was on consisted of several entry-level people who were taught COBOL. After a couple years or so most of us have moved on to better compensated positions at other companies.