The persistence of COBOL: why a 60-year old language is still in demand(idgconnect.com)
idgconnect.com
The persistence of COBOL: why a 60-year old language is still in demand
https://www.idgconnect.com/article/3578391/the-persistence-of-cobol-why-a-60-year-old-language-is-still-in-demand.html
12 comments
I actually went through something like this back in 1996. A few local companies (AFLAC, TSYS and Blue Cross/Blue Shield) sponsored a program that taught Assembler, COBOL, IMS, DB2, JCL, Rexx, etc. Those who made it through all the testing, interviews, background checks, etc. were paid to go to school 8 hours a day for 3 months. When you were done you were guaranteed a job at one of those companies, and you agreed to work there a minimum of 4 years to work off the money that was paid to you while you went through training. If you left the company before the time was up you had to pay back the remaining balance. This put all of us into working on mainframes during Y2K. Once Y2K was done I moved on to Java, then .NET, and now work in Machine Learning, 24 years later. It was a great way to get my foot in the door.
If you bring in most people with previous programming or systems exposure, they hear "COBOL", and make jokes about "COOL COBOL" (COBOL Object Orientated Language). This somewhat includes myself.
If you bring in someone who is smart, pragmatic, and interested in a nice indoor job with good pay, they're more interested in the specialized job training and position that comes with it.
Someone I knew made the tongue in cheek retirement joke that "where else could I learn COBOL and mainframe in university, and never learn anything else until I retired?"
If you bring in someone who is smart, pragmatic, and interested in a nice indoor job with good pay, they're more interested in the specialized job training and position that comes with it.
Someone I knew made the tongue in cheek retirement joke that "where else could I learn COBOL and mainframe in university, and never learn anything else until I retired?"
These two extremes I can't understand: people who never want to learn anything and people who seem to only want to use each framework once.
The problem is finding the middle ground. There's only so much I can learn, and only so much time to learn it. I don't want to spend my time spinning my wheels learning $NEXT_BIG_THING only for it to be superseded by $NEXT_BIG_THING+1 by the time I master it.
I think both are an example of an aversion to deep learning.
My personal theory is it's some mix of imposter syndrome and fear of missing out. If you don't keep up with the latest tech then sooner or later you'll be found out and ejected from the pack, never to draw another sv paycheck again.
COOL (for C Object Oriented Language) was the internal Microsoft name for what would become C#.
The jokes I heard were about ADD 1 TO COBOL GIVING COBOL, following the convention established by C++.
Recent versions of the COBOL standard, like Fortran and Ada, include object-oriented extensions.
The jokes I heard were about ADD 1 TO COBOL GIVING COBOL, following the convention established by C++.
Recent versions of the COBOL standard, like Fortran and Ada, include object-oriented extensions.
> and make jokes about "COOL COBOL" (COBOL Object Orientated Language)
I always assumed it'd be `POST-INCREMENT COBOL BY 1`
I always assumed it'd be `POST-INCREMENT COBOL BY 1`
You have a responsibility to yourself to keep your knowledge current and up to day so that you can thrive in the job market.
If your skill is in demand, get training in that domain.
If your skill belongs to a niche, be careful, consider how you can reuse the knowledge you are aquiring.
If your skill is in demand, get training in that domain.
If your skill belongs to a niche, be careful, consider how you can reuse the knowledge you are aquiring.
This is the key quote:
> It's important to recognise that the skills crisis is not simply about a shortage of people who understand how to code in the COBOL language. The deeper issue is the lack of application knowledge. Being able to code in COBOL is the first step. The really hard part is understanding what an application does.
We techies - programmers as well as business folks in tech - love to think that a programmer's most valuable skills are their knowledge of programming languages. It isn't, and never was. You can learn a programming language from a book, and practice it virtually anywhere. Domain knowledge, such as understanding the rules of a bureaucracy or a regulatory regime, can usually only be acquired through years of on-the-job training.
If there's a COBOL angle to this, it's what they highlight in the next paragraph: Tight coupling within COBOL monoliths, which is probably more a result of their age than their implementation language, has made it impossible for someone with less-than-extensive knowledge of the system they're working in to be able to work efficiently and effectively. I'm not sure what the solution to that problem is, but I don't think it's ever going to be a programming language.
> It's important to recognise that the skills crisis is not simply about a shortage of people who understand how to code in the COBOL language. The deeper issue is the lack of application knowledge. Being able to code in COBOL is the first step. The really hard part is understanding what an application does.
We techies - programmers as well as business folks in tech - love to think that a programmer's most valuable skills are their knowledge of programming languages. It isn't, and never was. You can learn a programming language from a book, and practice it virtually anywhere. Domain knowledge, such as understanding the rules of a bureaucracy or a regulatory regime, can usually only be acquired through years of on-the-job training.
If there's a COBOL angle to this, it's what they highlight in the next paragraph: Tight coupling within COBOL monoliths, which is probably more a result of their age than their implementation language, has made it impossible for someone with less-than-extensive knowledge of the system they're working in to be able to work efficiently and effectively. I'm not sure what the solution to that problem is, but I don't think it's ever going to be a programming language.
>We techies - programmers as well as business folks in tech - love to think that a programmer's most valuable skills are their knowledge of programming languages.
Until recently, this wasn't a common thought beyond the beginner stage.
I think the mindset comes from the demand to grind out websites. A short ramp up has become way more important than ability to learn on the job.
Programming isn't magic, one of our not-software disciplines has a tradition of learning python so they can make business logic changes to internal tooling we maintain for them. Not that it's hard for them to get on our schedule (they usually preempt our other work), it's just that it's so damn easy for someone smart to pick up python.
Until recently, this wasn't a common thought beyond the beginner stage.
I think the mindset comes from the demand to grind out websites. A short ramp up has become way more important than ability to learn on the job.
Programming isn't magic, one of our not-software disciplines has a tradition of learning python so they can make business logic changes to internal tooling we maintain for them. Not that it's hard for them to get on our schedule (they usually preempt our other work), it's just that it's so damn easy for someone smart to pick up python.
While it’s true in practice for most companies, I’ve always had the suspicion that if it takes years to learn a process, it often indicates a bad process full of tribal knowledge and loosely defined informal heuristics. I’d like to think competent people shouldn’t need years to understand a well-defined process
On the one hand, you're absolutely correct. On the other hand, we could handily rephrase that as a lame joke:
How many programmers does it take to screw in a light bulb?
One. They hold the light bulb still, and the entire office revolves around them.
How many programmers does it take to screw in a light bulb?
One. They hold the light bulb still, and the entire office revolves around them.
The problem with COBOL is not exactly the framework per se, it is the suspicion that the places that use it don't prize good engineering and don't have a sound technological leadership.
As per the Peter Drucker terminology, if you use COBOL then programming is likely a cost center in your organization.
True, it is a prejudice. Disregard for programmers is also common among organizations that adopt "cool" technologies. And quite often they also suffer from other specific problems (e.g.: ageism, obsession for the hype "du jour"). But prejudices are like that, they just happen.
As per the Peter Drucker terminology, if you use COBOL then programming is likely a cost center in your organization.
True, it is a prejudice. Disregard for programmers is also common among organizations that adopt "cool" technologies. And quite often they also suffer from other specific problems (e.g.: ageism, obsession for the hype "du jour"). But prejudices are like that, they just happen.
This rings true from the article. Note that one the biggest users stated are governments, not exactly known as bastions for valuing IT and being ahead of the curve. I have no issues with COBOL, but I’d like to know the why behind its continued use before joining that org.
After working for a couple organizations that had extremely old code infrastructure, there’s world of difference between “we maintain it because it’s the right technological risk” vs “we’re too lazy/scared/incompetent to move away from it”
After working for a couple organizations that had extremely old code infrastructure, there’s world of difference between “we maintain it because it’s the right technological risk” vs “we’re too lazy/scared/incompetent to move away from it”
> Note that one the biggest users stated are governments
Governments use to have extremely large databases of extremely critical data that has to be collected and processed in a secure, correct, and timely basis or the agency will be in breach of some law that governs it. It's not surprising they were early adopters of large computers.
Traditionally, everything that's not forbidden is implicitly permitted in private initiative. In government, it's usually the reverse: anything that's not explicitly allowed by law is forbidden. And sometimes a crime.
This selects for very risk-averse organizations. The environments where these COBOL programs run are also remarkably stable. If it's running now, it'll most likely continue to run for the next 20 years of software and hardware updates. A lot of systems still think they are reading and writing tapes.
Governments use to have extremely large databases of extremely critical data that has to be collected and processed in a secure, correct, and timely basis or the agency will be in breach of some law that governs it. It's not surprising they were early adopters of large computers.
Traditionally, everything that's not forbidden is implicitly permitted in private initiative. In government, it's usually the reverse: anything that's not explicitly allowed by law is forbidden. And sometimes a crime.
This selects for very risk-averse organizations. The environments where these COBOL programs run are also remarkably stable. If it's running now, it'll most likely continue to run for the next 20 years of software and hardware updates. A lot of systems still think they are reading and writing tapes.
I would tend to agree and would classify those reasons you stated as the "right technical risk" category.
Although I don't think it's quite as bad as anything not being explicitly allowed is deemed illegal. It's not quite that strict, project managers can modernize just within certain limits (e.g., you can't just host on any cloud, but must be on a government approved cloud service).
However, I have worked in some of those environments where programmers refused to change, admittedly due to their unwillingness to learn despite their customer wanting the change. Even at organizations with large risk-adverse datasets, there's a desire to change but an inability to execute. The VA for example, has struggled for decades to modernize their system despite sinking millions and millions of dollars into it.
>If it's running now, it'll most likely continue to run for the next 20 years of software and hardware updates.
This is fine if the system is expected to remain static. Problems often arise when hardware or software are expected to change and still run the same legacy code.
However, I have worked in some of those environments where programmers refused to change, admittedly due to their unwillingness to learn despite their customer wanting the change. Even at organizations with large risk-adverse datasets, there's a desire to change but an inability to execute. The VA for example, has struggled for decades to modernize their system despite sinking millions and millions of dollars into it.
>If it's running now, it'll most likely continue to run for the next 20 years of software and hardware updates.
This is fine if the system is expected to remain static. Problems often arise when hardware or software are expected to change and still run the same legacy code.
> Problems often arise when hardware or software are expected to change and still run the same legacy code.
One of the selling points of IBM mainframes is the pretty flawless backwards compatibility. I wouldn't be surprised if you could run unmodified binaries compiled for the 360 model 20 on a z15.
One of the selling points of IBM mainframes is the pretty flawless backwards compatibility. I wouldn't be surprised if you could run unmodified binaries compiled for the 360 model 20 on a z15.
I keep reading that COBOL skills are "in demand", but I keep not seeing evidence of it in terms of actual salaries. Machine learning is actually in demand - it pays well.
I believe much of the salary is an effect on the institutions that need the programmers.
Governments are often the organizations needing COBOL programmers, but government salaries are not commensurate with the tech industry (often due to bureaucratic limits), especially when compared to the consumer tech industry. In that context, pay caps out at around $170k no matter how in demand the skill is
Governments are often the organizations needing COBOL programmers, but government salaries are not commensurate with the tech industry (often due to bureaucratic limits), especially when compared to the consumer tech industry. In that context, pay caps out at around $170k no matter how in demand the skill is
As long as people maintain their code it will stay fresh and up to date. Framework is irrelevant.
The moment you stop maintaining your code your system will grow old very fast.
Cobol has just a different stink than the language you are familiar with.
The moment you stop maintaining your code your system will grow old very fast.
Cobol has just a different stink than the language you are familiar with.
Python is 30 years old, SQL is ~45 years old, Java is 30 years old, C is 50 years old. There are newer developments obviously but 60 years is not really all that much of an outlier for a programming language.
You can add for example assembler on C64 or Amiga to the list.
Highly vital demoscene and even new games released on both platforms.
Highly vital demoscene and even new games released on both platforms.
Whenever COBOL or Fortran is mentioned, it is met with so much criticism. Such an archaic ugly language. OMG why didn't they replace it with C#/JAVA/whatever yet. Who would learn an obsolete language? It's a dead end as a developer.
Well guess what, it most likely will outlive every other language and framework created in the last 10 years by a large margin.
I just wish it would pay better to attract senior developers. The language is easy, but it has to be a real challenge understanding all of the interconnected processes and that requires a lot of experience. Surely there are many who would choose a COBOL job over learning a new framework every 2 years.
Well guess what, it most likely will outlive every other language and framework created in the last 10 years by a large margin.
I just wish it would pay better to attract senior developers. The language is easy, but it has to be a real challenge understanding all of the interconnected processes and that requires a lot of experience. Surely there are many who would choose a COBOL job over learning a new framework every 2 years.
Why you talk first about C#/Java and then language of last decade? Both of those languages are >2 decades old.
I think it's very naive to think that COBOL will outlive Java or C#. Their presence is so huge. I bet that even Rust and Go will outlive COBOL, but I'm not so sure about Go.
I think it's very naive to think that COBOL will outlive Java or C#. Their presence is so huge. I bet that even Rust and Go will outlive COBOL, but I'm not so sure about Go.
Yeah that was worded badly, I didn't want to imply that it will outlive those languages. The thought was more about "it's a dead and obsolete language" uttered by developers that jump from one language/framework to another. Recent stuff will die out and is replaced quickly by design.
Java on the other hand has potential to become the next COBOL in the far future.
Java on the other hand has potential to become the next COBOL in the far future.
Plus, if you write COBOL code, chances are it's running on some mainframe, which are the coolest computers you can get, for any amount of money.
Another reason for COBOL in business settings: support for BCD arithmetic. Binary floating point can yield up some interesting rounding errors if you aren't extra careful.
Did somebody think the code would somehow disappear.
I can tell you from first-hand experience people expected the systems would be gradually migrated to new languages (and out of mainframes) at some point in the 1990's.
A lot of those migrations failed miserably. Others failed spectacularly.
A lot of those migrations failed miserably. Others failed spectacularly.
That was the mindset that got us the Y2K bug 20 years ago.
I remember seeing a lot of fixes for the Y2K bug that looked like this, too:
I remember seeing a lot of fixes for the Y2K bug that looked like this, too:
if (year > 50) {
year += 1900;
} else {
year += 2000;
}
Using two digits for years is not a language issue. You can migrate your systems from 2 to 4 digits without having to rewrite your code in Java 1.2.
This was, in fact, how most of it was done.
This was, in fact, how most of it was done.
Hopefully code like this is marked with a standard comment for future grepping.
[deleted]
s/50/70/
For me, it’s mostly because if you have a significant install, there is no clear substitute.
I don’t want to migrate 70.000 programs to a new language that will become a fad in 5 years. You cannot rewrite some systems (banking, aerospace, defence, energy,...) from zero every 5-10 years.
I don’t want to migrate 70.000 programs to a new language that will become a fad in 5 years. You cannot rewrite some systems (banking, aerospace, defence, energy,...) from zero every 5-10 years.
Java and C# have been industry standard in enterprise for 20+ years now ? There are order of magnitude more trained devs, infrastructure, etc. and risk of getting obsolete in 5-10 years seems negligible. Even then the support community will be order of magnitude greater since so much of existing infrastructure is running those stacks and SW is orders of magnitude greater than it was in COBOL days.
You don't need to jump on flavour of the month stack just because you are doing a rewrite.
You don't need to jump on flavour of the month stack just because you are doing a rewrite.
COBOL is sort of a DSL for business logic. Java and C# are not.
>COBOL is sort of a DSL for business logic
It was intended to be that, but ended up being a DSL for machine code. The same happened to SQL.
It was intended to be that, but ended up being a DSL for machine code. The same happened to SQL.
Is Cobol used as much outside of the U.S? Most of the articles are U.S. centric and don't really metnion the global perspective.
I know it's used in banks in some countries in Latin America, where the COBOL codebase is old, decrepit, and stinks. It's a career dead-end (tech-wise at least; money-wise it can be smart[1]) to get a job in COBOL as used in banks.
[1] Though, to be honest, the claim that you should learn COBOL because there's a shortage of programmers and it pays well is not particularly true. Nobody I know of is making big money with COBOL. It's mostly an average-paying, uninteresting programming job. You'll probably make money by climbing through the ranks within the bank organization, where your COBOL skills will become slowly irrelevant.
[1] Though, to be honest, the claim that you should learn COBOL because there's a shortage of programmers and it pays well is not particularly true. Nobody I know of is making big money with COBOL. It's mostly an average-paying, uninteresting programming job. You'll probably make money by climbing through the ranks within the bank organization, where your COBOL skills will become slowly irrelevant.
I don't think so, since it was mostly used for federal agencies and national banks in America.
Rather than needing to program directly in COBOL, are there any compromise solutions for this, like a code analyzer/generator that allows a programmer to code in a higher-level language but outputs COBOL?
I think there are two parts to this I should address:
Yes, there are frames that go on top of COBOL. But a lot of the reasons to actually use COBOL come down to:
- there are 300+ applications on your mainframe, and each has an interface, associated queues, code table, and calling conventions which are specified in COBOL
- correctness of solution, and proving it correct
- the field twiddling decisions based on data are low level, "inspect field A, do X, else do Y, afterwards save A2 and send message B", that doesn't appear to leverage well into a higher language
- tooling on the mainframe supports COBOL quite well, there is a lot of infrastructure which very very smart people have put in place over the last several decades
So there's a lot reasons why COBOL "fits" in the current space. It's not cool though. And that inertia is worth multiples of billions of dollars in invested time, and replacement costs for like-with-somewhat-better can easily hit trillions of dollars. I don't really want to do the envelope math, because some applications are ~1 million, and some are 100-250 million to replace.
The HR issue is clearly something that organizations know about, and have been trying to address for literally decades. COBOL was passe in 1995, and 2000, and still is, but as an industry we're still addressing this issue in 2020.
The other aspect of your question that I'd like to address is: why not program in COBOL? What does a code generator give you? what are you gaining? I'm trying to ask a question about mentality towards COBOL. COBOL can be compiled just like any other language down to efficient byte code. If we had a supposed "10x DevOps program engineer", what makes COBOL something that they couldn't master and leverage in a month? The experiences gained wouldn't simple be "COBOL programming", it would be an entire development and run environment, release and CI approaches, etc.
All that said, I had the opportunity to work in COBOL, and I passed on it, so I can understand as an average programmer why not to work in it.
Yes, there are frames that go on top of COBOL. But a lot of the reasons to actually use COBOL come down to:
- there are 300+ applications on your mainframe, and each has an interface, associated queues, code table, and calling conventions which are specified in COBOL
- correctness of solution, and proving it correct
- the field twiddling decisions based on data are low level, "inspect field A, do X, else do Y, afterwards save A2 and send message B", that doesn't appear to leverage well into a higher language
- tooling on the mainframe supports COBOL quite well, there is a lot of infrastructure which very very smart people have put in place over the last several decades
So there's a lot reasons why COBOL "fits" in the current space. It's not cool though. And that inertia is worth multiples of billions of dollars in invested time, and replacement costs for like-with-somewhat-better can easily hit trillions of dollars. I don't really want to do the envelope math, because some applications are ~1 million, and some are 100-250 million to replace.
The HR issue is clearly something that organizations know about, and have been trying to address for literally decades. COBOL was passe in 1995, and 2000, and still is, but as an industry we're still addressing this issue in 2020.
The other aspect of your question that I'd like to address is: why not program in COBOL? What does a code generator give you? what are you gaining? I'm trying to ask a question about mentality towards COBOL. COBOL can be compiled just like any other language down to efficient byte code. If we had a supposed "10x DevOps program engineer", what makes COBOL something that they couldn't master and leverage in a month? The experiences gained wouldn't simple be "COBOL programming", it would be an entire development and run environment, release and CI approaches, etc.
All that said, I had the opportunity to work in COBOL, and I passed on it, so I can understand as an average programmer why not to work in it.
The problem isn't that the computers can't run anything other than COBOL, the problem is that the critical software is in COBOL and needs to be maintained.
I clarified my question. Not looking to replace COBOL, but tooling that helps you write it but in a higher-level language. The other reply from skylanh answered my question.
Yeah, e.g. this:
https://en.wikipedia.org/wiki/EGL_(programming_language)
It can output COBOL if the target is mainframe but also e.g. Java if your target is Linux or Windows.
(haven't coded it myself but seen it in action several places)
https://www.glassdoor.com/Salaries/cobol-programmer-salary-S...
Doesn't look like it's in demand compared to current hotness (React/Angular/ML). It's still a dead end for anyone wanting to pursue a career in software engineering.
Doesn't look like it's in demand compared to current hotness (React/Angular/ML). It's still a dead end for anyone wanting to pursue a career in software engineering.
I would turn this around and say:
Find a list of:
- consumer and commercial insurance companies
- healthcare insurance companies
- retail banks
- any industry that has been doing high thoroughput, large value, and large volume sales in a very constrained environment for more than 30 years: oil and gas, ocean and rail cargo shipping, commodity sales brokers
- every major government with a digital infrastructure older than 30 years (this brings us back to pre-1990, mainframe was the only real option back then)
I would posit that in each of these areas you will find very well paying jobs, very demanding and interesting work that's critical, and some extremely smart coworkers.
I would go further to say that if you showed up unannounced with a security clearance, history, resume, and credible reference checks, that you could have a letter of offer (as quickly as the wheels of bureaucracy spin) and salary you could negotiate on.
Find a list of:
- consumer and commercial insurance companies
- healthcare insurance companies
- retail banks
- any industry that has been doing high thoroughput, large value, and large volume sales in a very constrained environment for more than 30 years: oil and gas, ocean and rail cargo shipping, commodity sales brokers
- every major government with a digital infrastructure older than 30 years (this brings us back to pre-1990, mainframe was the only real option back then)
I would posit that in each of these areas you will find very well paying jobs, very demanding and interesting work that's critical, and some extremely smart coworkers.
I would go further to say that if you showed up unannounced with a security clearance, history, resume, and credible reference checks, that you could have a letter of offer (as quickly as the wheels of bureaucracy spin) and salary you could negotiate on.
...and salary you could negotiate on.
Not even remotely true. COBOL programming is very, very badly paid.
Not even remotely true. COBOL programming is very, very badly paid.
Let’s see if react/angular can make it 60 years.
I think they're just trying to say that your best bet for a good salary and variety of places to live would be to choose something modern (and in demand) and then stay up to date on as much as you can so you can always stay mobile. Focusing on only one technology is a bad idea as most modern technologies have definite cycles.
Heaven forbid!
Their reasoning was it would be easier to train new individuals and work them up, using senior staff as trainers and escalation points than to try and find existing COBOL programmers. They started the pay off quite well and were able to pull in some highly talented people. They approached it almost like an apprenticeship, only with programming as the trade.