>There’s nothing wrong with the language itself, the problem is that barely anyone knows it — at least not in the context of mainframe programming.
What data did you use to determine that barely anyone knows mainframe COBOL? There are a significant amount of companies that still use it because it just works and they're in no need to upgrade to current technologies.
I don't have any data for that point, but I get the sense that this shortage of labor is caused more by aging workforce than obscurity. My dad is an engineering manager for a large credit card processor that uses a very similar mainframe setup, and they're constantly putting enormous pressure on their offshore contracting firms to provide young COBOL programmers because they can barely find them here. It's a job that pays people enough that they can retire well if they're good with money, and they're retiring constantly. At 57, he's one of the youngest on the team.
I was involved in this for a couple of years in the mid-90s working for a COBOL vendor helping people migrate from mainframes and minicomputers to what was known as the “open systems” (mostly Unix, with Windows NT rising) world, saving a somewhat jaw-dropping amount of cash in annual licensing and support costs.
Even back then, one of the major complaints was that companies refused to pay for training, hoping they'd find someone who already knew everything they needed. I heard multiple stories about people who told their employer that they were planning to retire, left on schedule after not finding anyone qualified to train, and returned later as a consultant at a significantly higher rate.
Many younger programmers wouldn't want to get into mainframe Cobol programming because of the almost compulsory requirement to provide after-hours support duties in most of these jobs. Many managers find it easier to let programmers get woken up at night to fix the problems instead of allowing them to prevent the problems from occuring beforehand during the daytime. Years of getting woken up at 3 in the morning to fix those types of production problems tends to make many people look for other lines of work. The people who do stay employed doing after-hours support are often the ones who deliberately put the problems into the code during the daytime, generating those money-making callouts. US businesses with some India-based programmers will utilize them to fix those overnight problems because of the time zone difference.
The phrase "their offshore contracting firms" there should be enough to make any sensible 20 year old run screaming. Sure, spend a bunch of time learning a dead language, to get paid peanuts and be replaced by an offshore worker within a year, no problem!
unfortunately even assuming the outsourcer can find people who really have COBOL experience there's a world of difference between knowing COBOL and being able to maintain the 30+ years of hacks that many large companies will have built up in these systems.
Unfortunately the alternative (re-write the mainframe/COBOL systems in a more modern platform) is a risky and costly process....
> being able to maintain the 30+ years of hacks that many large companies will have built up in these systems.
It's not even the hacks. It's that "how the business works" was automated into COBOL 30 or 40 years ago, everyone in the "business" who knew how and why things happened retired or got laid off, and the COBOL programmers are the only ones who remember the business rules.
In college a few years ago I had to work with a system written in FORTRAN 77 in the early 90s that has been hacked new features and bug fixes on and off for almost 20 years, one single file with more than 20k lines of code, it worked all right, but understanding it was troublesome.
I lost the count of how many times I thought about rewriting the entire beast in C or even a more recent iteration of FORTRAN.
In the end, it wasn't something that I would use for much longer and I just mapped what all functions that i needed did on a spreadsheet and added a couple of hacks for the next unfortunate person to handle.
Maintaining old codebases full of hacks and without good documentation that can fail without big consequences is boring, but code that handles the kind of data that banks have is something straight from hell.
What I believe the parent is referring to is that there is an acknowledged shortage of COBOL programmers. See http://blog.stafflink.ca/recruiting-tips/cobol-and-the-mainf... or just google COBOL programmers shortage. There are still plenty of COBOL programmers (and jobs) but most are 45+ with many retired or retiring shortly. Why not train replacements? Schools tend not to train students in procedural programming or mainframe programming so there's a fairly hefty ramp-up period (2-3 YEARS with the possibility that the person may leave at any time during or after training). This COBOL shortage tends to be a large reason why many companies are replacing COBOL systems with systems written in Java or .NET.
That said, mainframes and COBOL tend to be used heavily at utilities, railroads, and government entities. One of my coworkers (one of two former COBOL programmers on staff) just identified that Eversource in CT uses COBOL because of their inability to handle a certain type of id.
My first job out of school, at a big consulting firm, and they were teaching new college graduates COBOL in a 6-week bootcamp. And most of them had taken few or no programming courses in school.
yes language are NOT difficult, it's the same concept everywhere (conditions / loop / boolean logic / etc)
BUT the hard part was, is and will always be domain knowledge, with special cases here & there, obscure logic, miscommunication between expert & developer and others
Few people know it but it was written with the idea of very human-like descriptions of what's to be done. I'd wager anyone with a basic introduction to programming could quickly become productive in the language. Although you wouldn't guess it if you went to my college in the early 80s.
For reasons only known to my computer science dean COBOL was a third year course after after BASIC, Pascal and FORTRAN in 1985 or so when I was working through the curriculum for a CS degree. Fourth year was BAL (IBM mainframe assembly) followed by a language of your own design.
That it works and that "barely anyone knows it" are not contradictory.
Fortran (particularly in the context of embedded systems developed in the 70s and 80s) is another "barely known" language that's quite widely used (particularly in historical and maintenance contexts, if not in widespread current development outside certain engineering and scientific domains).
I've seen mainframe users in the UK (e.g. banks) trying to hire new COBOL programmers because (as the article says) all the original ones are retiring.
Unfortunately young people might not find the world of mainframes and COBOL the most enticing career choice :)
I think it will be a huge problem over the coming years as more of the original authors of banking system retire.
What data did you use to determine that barely anyone knows mainframe COBOL? There are a significant amount of companies that still use it because it just works and they're in no need to upgrade to current technologies.