This COBOL shortage myth has been around since I was a kid. It wasn't true then, and isn't now.

The entire problem is that they don't pay well for what is supposedly a rare resource. And nobody wants to learn a dead language for peanuts.

Offer 500k/yr, and me and about 100 million other people will be learning COBOL starting tomorrow.

Right. COBOL is not some mythical ancient knowledge that can't be learned today. I'm pretty sure anyone who can learn Haskell can learn COBOL too, it's just a question of making them want to.

500? Try 250. Heck, 150 if we can work from home

The problem is now you have a bunch of D-level cobol coders without any experience, domain knowledge, etc

Which is where we are with most Java dev shops.

> The problem is now you have a bunch of D-level cobol coders without any experience, domain knowledge, etc

Right? So don’t wait too long because all of those who can pass this knowledge will be gone!

Also there are a ton of working programers that have some experience in cobol from school.

But everyone knows it’s a dead end. So yeah they need to pay very well to get the fixed they need.

Sounds like it isn't a myth - you yourself admit there aren't people who know it, just that would OFFER to learn it given the appropriate compensation.

By that logic, there isn't a shortage of anything if you have enough money.

The 'myth' since the early 90s is that you should definitely study COBOL because you'll be set for life because of the big shortage.

Right... they can't train someone on COBOL? I call b.s. on that. It's an HR issue, you need blah blah degrees and yadi yadi yada experience. Big corps don't adopt to job economy changes over time like this unless their core business is built to adopt to economic changes. Inability to make exemptions and place the right first line managers over teams is what kills big companies, or forces them into an endless loop of unoriginal aquisitions and failures imo.

Banks are genetically incapable of doing anything useful in terms of technology. Their mainframe architecture was outdated 40 years ago! They will forever maintain their hacks and buggy software.

Please define "buggy software." Can you point to a single confirmed case in the US of a person's bank account balance disappearing, or even a deposit not appearing, due to a software bug? I doubt it. Banks' core software is rock solid or they would be out of business very, very quickly.

You've cited two comparatively minor failures confined to a very small subset of what banks do. There's a whole lot of critical software systems in banks that don't touch personal bank accounts. If you've ever worked on bank systems before, it was certainly in a very limited capacity.

I did code-level support for a large internal data management system for the federal reserve bank in the mid aughts. I'm not really interested in disclosing the specific bland but critically important data we moved/managed. It involved a giant amalgam of legacy commercial AIX and HP-UX software with some newer Java stuff in a Websphere environment. It was all duct-tape-and-bubble-gummed together with huge ksh88 scripts that were in constant development by devs and support people like me who'd just ssh into production systems to make changes. None of the internal software had dev/test systems, there was definitely no code review, and there was no version control. Yep. The system on a whole required constant monitoring and intervention to keep it plodding along. We did periodically see data loss that was unrecoverable from a technological standpoint but recovered with physical media kept around from their necessarily belt-and-suspenders business practices and tons of available staff for data entry. I reckon tens-of-thousands of folks outside the bank would have been affected per incident.

Money disappearing from a bank account is a "comparatively minor failure"? Sorry, I stopped reading at that point.

If you're committed to not knowing something then I can't stop you.

But compared to, say, tens of thousands of investment transactions for pension and retirement funds evaporating, disbursements to a hospital's operations budget being delayed, sending confidential historical balance records in bulk to a large corporate customer's competitor, having an online investment system down during a period of extreme market volatility, or even large-scale customer data breaches, then yes. 'Money missing from a bank account' is in every significant way a comparatively minor problem probably fixable with a phone call and a couple hours of investigation on the bank's part, even with a significant sum of money. The bank would almost certainly catch it themselves during an automated audit. It's exactly the sort of problem that bookkeeping organizations are designed to mitigate and root out if they do happen.

The others could affect many, many more people's lives for much longer— potentially permanently.

Has that really not happened to you or someone you know? It is (typically) eventually recovered, yes; and you can often understand how/why it happened. But it definitely happens, and requires manual human intervention for fixing. Here's 2 incidents that happened to me or friends in the last month:

- took a trip to the neighboring country, my friend tried to take out money from an ATM; first two transactions failed, third succeeded (at the atm). In the bank though, all "succeeded", and money were gone (first 2 eventually were reversed with manual intervention).

- I sold a house (in a remote mountain village), buyer sent 8100EUR from Germany, 78xy.z EUR made it to my personal bank account. Apparently due to multiple currency exchanges, but this is a SEPA transfer between two accounts both denominated in EUR, this was absolutely not supposed to happen and nobody was able to articulate exactly "why it happened" (or even exactly what happened). For this one the buyer decided to just eat the loss and sent me an additional 300EUR.

Money disappearing is a minor failure in the sense that it is easy to track. Banks do daily audits to check that money sent in one side is deposited in another. If there is any issue, they will track it and rectify within the 3 days grace period created exactly to work around these bugs.

There have been major bank tech failures too, if you wanted to see major vs minor side by side...

Not the US, but in the UK which I think is comparable:

* https://www.theguardian.com/money/2015/aug/28/many-hsbc-cust... (I believe this one was caused by firing greybeards who understood a certain very complicated batch processing system and offshoring to undertrained staff in India who then make a mistake and basically brough the entire system down as a knock-on effect)

* https://www.theguardian.com/business/2019/nov/19/tsb-it-melt... (Insufficiently tested software upgrade although to be fair this was a major upgrade)

* https://scottishfinancialnews.com/article/rbs-it-failure-pre... (Not sure on root cause. Other interesting stats at the bottom of the article regarding failure counts)

Now, in all these cases I believe the outages lasted a few days at least where people had limited or no access to bank accounts, salaries not paid on time, incorrectly charged overdraft fees, automated payments not happening etc.

It can probably be argued what is "core" here and as far as I know no money actually disappeared into the ether but, in the UK at least, I am not sure I would be so confident in my declaration of Rock Solid software.

Thanks, these examples confirm my point. The old, ancient, "outdated" (as the original poster claimed) software worked fine for years/decades. The failures that you cited were introduced during an upgrade, a rewrite/outsourcing, or due to a 3rd party outage.

But requirements change, so upgrades are a normal part of business, due to at the bare minimum legal reporting requirements changing, even if there weren't all sorts of new things like internet banking making their old APIs inadequate.

If the software isn't extendable or changeable then it isn't 'working fine', because if you can't offer internet banking or do FATCA reporting you go out of business or get shut down.

Transaction reversibility, fear of law enforcement and the ability to react to things is the reason why the bank tire fire doesn't collapse on itself.

im sure glad the cryptocurrency folks seem intent on throwing all three of those away at once.

Banks have procedures and regulations that protect customers from those issues. In fact there's a lot of of secondary checks and offline reconciliation precisely to catch potential software errors.

It is not, based on the loopholes one has to jump through for basic support.

What do you mean by 'useful' here? Facebook goes down for half a day and everybody laughs. Take 'banks' down for the same amount of time and see what happens.

It's pretty standard for banks to "go down" outside the hours of 9am-5pm. Nearly everything meaningful that a bank does is processed in batch, often with days-long delays.

Operationally, Facebook is a vastly harder problem.

Multi-hour outages are already relatively common and getting more frequent by the year for banks. About 10 days ago there was a massive Bank of America outage.

You certainly don't use banks often, because their systems being offline for several hours is a relative common event.

Not if they can’t find anyone willing to learn COBOL.

There’s huge demand for developers on modern systems. Seriously, how much are you going to pay a developer to do mainframe COBOL - and is that developer going to produce commensurate value, really able to hold together a crumbling antique infrastructure?

Plenty of people working helpdesk that know a bit of python who can learn COBOL if they knew a job offer was on the other end of the investment in learning the language. There are hoards of people learning python and powershell just so they can make more money, trust me when I say they (the people I see learning python for career prospects) have no sentimental attachment to the language.

I don't think it's learning COBOL language that's the hard part. An inexperienced programmer who hasn't worked on financial systems is going to make security mistakes and write buggy code for awhile, both of which can be deadly to a bank. But it would be better to have that person rewrite the infrastructure than try to fix bugs. The problem with these ancient systems is trying to understand how bugs arise from subtle unintended interactions within millions of lines of code. I've been coding many languages for 25 years and I would consider it extremely daunting to try to tackle a bank bug knowing that one wrong assumption about one line of code could crash whole systems or cost millions of dollars.

Eh, someone's got to do it. Letting thing stagnate in perpetuity isn't cheap either. Move slowly and write tests.

Sure, but a veteran coder at least understands that tampering with something may affect some other subsystem you don't even know exists until it breaks... which you wouldn't even think to test. The idea of throwing the phone staff into COBOL instead of them learning Python just obfuscates the real problem which isn't that the language is uncool and dying but that the systems are like the rules of the NFL. They stopped making sense a long time ago to anyone who wasn't immersed and paying attention.

Ah, yeah, fully agree - I just saw your mention of having 25 years experience, which made me think basically "if not you, then who?"

I didn’t intend to imply that the problem could be solved by an army of people fresh out of boot camps with no senior level supervision.

I'm also realizing now that just because you "would consider it extremely daunting" does not necessarily mean that you don't think you could be a net positive contributor.

Fwiw, one of the highest paid coders I ever knew worked for a big stuffy bank. He was unfireable because he was the only one that knew the internal systems as well as he did. Learning COBOL may be a huge long term competitive advantage in the workforce, especially if the current dotcom-esque funny money dries up.

For enough money they will find someone willing to learn COBOL.

Maybe, or maybe not.

Suppose you accept 1.5x or 2x or even 3x your annual salary to take a COBOL job. Nice... for now.

What happens in 2, 5, or 10 years when this COBOL gig ends?

Now your skills have withered or disappeared and you're 2, 5, or 10 years behind when it comes to "modern" technologies where 99.9% of the job opportunities are.

In a sense, that COBOL job is a gamble. You are gambling that you can ride that sucker until retirement.

Of course there are other possibilities. You could sock most of that extra $$$ away and spend a year retraining yourself, or something, if/when that COBOL job ends. Or whatever.

I'd rather learn COBOL and get paid 2x salary for the next 5 years than learn some BS JS framework that I'll have to forget in the same timeframe.

React has been around for 8 years and isn't going anywhere anytime soon.

Staking a career on something that has existed for only 8 years is a huge gamble. Most people build careers around concepts and tools that have existed anywhere from decades to millennia.

> What happens in 2, 5, or 10 years when this COBOL ends?

What happens in 1 or 2 years when the current hottest new full-stack, mvc, reactive 3.0 whatever is old and tired and you have to learn the new thing? You learn the new thing.

Sorry, I forgot a word there. Post now edited.

I meant, "when this COBOL gig ends", not "when this COBOL ends" which is what I initially typed.

I agree that COBOL will outlive a lot of these modern flash-in-the-pan frameworks.

However, the number of COBOL jobs will dwindle over time, and if I took a theoretical COBOL job today it's not clear to me that I would be particularly employable if/when that job ended. Particularly if I am unable/unwilling to relocate as I suspect COBOL jobs may be much less likely to be remote.

Whereas, in comparison, if one stays current in Ruby/Python/JS/.NET/Java then one's prospects would remain strong for the forseeable future. "Staying current" on the tech treadmill is of course its own special hell, but it is probably the safer road.

    What happens in 1 or 2 years when the current 
    hottest new full-stack, mvc, reactive 3.0 whatever 
    is old and tired and you have to learn the new 
    thing? You learn the new thing. 

OK, but how employable are you at that point?

It's going to take some significant effort to catch back up.

Perhaps more crucially, your resume is not going to be appealing to potential employers. If they're looking for hotshots in the latest framework, do you think they're going to look kindly upon a candidate who's spent the last X years working with COBOL?

There are ways to address that, such as getting up to speed in Trendy Framework XYZ and making some portfolio pieces, open source contributions, etc. But, that's not always a smooth road.

>OK, but how employable are you at that point?

>It's going to take some significant effort to catch back up.

You got 2x (or whatever) the salary until then. That should give you plenty of time to catch up. Currently anybody is employed anyways if one knows how to use a keyboard. I don't think that is ending anytime soon.

    You got 2x (or whatever) the salary until then. 
    That should give you plenty of time to catch up. 

You can catch up, but your resume can't.

Let's say you take a cushy COBOL job for X years and then spend Y years on your own "catching up."

At that point you're pretty proficient in whatever the trendy thing is at that time.

But what do recruiters see? They see, "this person hasn't worked with anything modern in X+Y years, and hasn't even had a job in Y years"

It can be overcome, but... not ideal.

    Currently anybody is employed anyways if one knows 
    how to use a keyboard. I don't think that is ending
    anytime soon. 

It might still be that way in X+Y years. It might not.

In fairness, the new things tend to build on top of each other. You can get off and on the treadmill but it comes with a cost.

Will they learn enough COBOL to be worth the money? Seeing how hard it is to find good mobile developers, and having lived in a COBOL shop back in the heyday, I don’t see a meaningful number of talented “show me the money” types passing up modern tech for antiques.

>> crumbling antique infrastructure

Are you talking about the hardware or software? It's worth considering that Lindy's Law [1] might apply here.

1. https://en.wikipedia.org/wiki/Lindy_effect

Decades-old does not mean duct-taped. It means every edge case has been hit, it's rock solid, and it works. There are many patches on top of patches, and the system is hard to comprehend for someone new. But it's a heck of a lot more stable that something redesigned.

The real issue here, is during bad weather and understaffed ATC, for some reason the airforce decided to do some training in airspace used by commercial flights. This military training part in the article is mentioned quickly, then completely ignored.

This was the US Military causing delays, cancellations, and people getting stuck overnight at airports. This was the US Military causing huge operational and financial issues for one of the most customer-friendly airlines out there. And the did this while eating up millions of dollars that are taken out of our paychecks - that they used to screw us. Time for congress to remove the funds that allowed them to conduct this training at a time when it caused problems for the general population paying their salaries.

If the cause is the military, why is southwest so disproportionately affected, and being affected in so many cities?

> “The problems weren’t concentrated in just one particular region. The cancelations affected the entire Southwest network. People living in cities where Southwest has a big operation, like Phoenix, Denver, Las Vegas, Los Angeles, and where I am in the San Francisco Bay Area, saw cancelations in the double-digits.”

an airport is a hub for an airline, but not for other airlines. if southwest has 50 planes at an airport, and delta has 10 southwest is going to be impacted. when your plane takeoffs are cancelled at your hub, every single flight that was going to use that plane later in the day, or the following day, is now missing a plane.

if Chicago O'hare is shut down, United is done for the day in half the country, because half its planes are stuck at O'hare. if Chicago Midway is shut down, only Southwest is screwed. if Atlanta shuts down, only Delta is screwed.

Yes, I'm sure there are other cities that also had planes. Like Phoenix. Except the plane that was supposed to land in Phoenix is stuck in Florida. Or the pilot piloting the plane already in Phoenix is stuck in Florida.

Planes go from one city to another. If you introduce a blockage along the way, you've now taken that plane, or a crew out of commission.

Decades old might definitely mean duct taped and unstable. In about 1995 I witnessed the beginning of the end of at the time very successful company that just had tripled their whole organisation. But the code base was 5 million lines of a lot of copy pasted literal spaghetti code. And only a handful of ageing coders that had been with the company almost from the start could get anything done. And then, one day, those damn customers demanded a Windows application, instead of the classy DOS application.

Decades-old, duct-taped architecture is endemic across the airline industry though, and AFAIK Southwest isn't even particularly bad on this front. American Airlines's original reservation system Sabre, still a major GDS player today, was first put together in the 1950s and is by some reckonings the oldest commercial (as in, non-government/military/research) computer system out there.

https://en.wikipedia.org/wiki/Sabre_(computer_system)

Southwest are better than most NA carriers in this regard, they switched to Amadeus a few years ago. Which is "only" 10-30 years old (depending on the components).

Not exactly but https://en.m.wikipedia.org/wiki/Knight_Capital_Group

It is maddening. Even if the stated goal is to “get off the mainframe” everybody deep down knows it isn’t going anywhere for 10 years. We recently had a discussion about porting from one mainframe “module” to another due to cost. I asked why we don’t just continue paying for the current module since the goal is to sunset mainframe. Everybody on the call laughed.

So we will go ahead and “invest” several man years and god knows how much money into a platform everybody agrees we should get off of.

I've been on the other side of this and seen too many teams neglect to fix even the simplest and most frustrating bugs in a system because they're going to rewrite it "in the next six months". Usually the rewrite is still going years later, and the actual code used in production is left to rot, holding back other teams as well.

It happens when you have a lot of new people who refuse to work with legacy code (which is anything over 2 years old), trivialize the complexity of the existing system (because they don’t understand a tenth of what it does), go create a sub par replacement with tons of people and years of work (that ends up coupled to the legacy system anyways), and now the company has two systems to maintain requiring double the resources as before. When everyone gets fed up and leaves, the cycle will start again. Our system is about four levels deep now. It’s the f’ing matrix.

Most of the new development I've worked on has been terrible, I attribute it to agile and the two week sprints churning out non stop MVP code that's technical debt from day one.

Can you blame them? These are the same teams who typically refuse to adopt practices that would allow them to create tests and we'll encapsulated designs. So inevitably the team is once bitten twice shy about breaking production. Why be the poor bastard who introduced anything but the tiniest bugfix?

I definitely agree it's a matter of incentives. Even in an environment with a now healthier quality culture, fixing bugs to bring an old system from 70% functionality to 100% is typically a career dead end.

It's much better to leave it broken and build a new system with 105% functionality so you can take credit for the whole 105%.

And typically, optimists that we are, it seems like completely reimplementing the original functionality will be "trivial" compared to merely trying to understand how the existing solution works.

> decades-old, duct-taped architecture

The way the survivorship bias works out, this is generally a strength, not a weakness.

You want to get good money, you learn how stuff works under the hood and get familiar with your predecessor architectures, emulate them if you need to.

I have to disagree. These systems aren't "survivors" - they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge. Often treated as a black box, they become an object that people have to hand-nurse through issues that would never trouble modern systems. The amount of effort and money that's expended to maintain these systems is typically far more than the upfront cost would be to replace them every decade with a more modern one, but that would look bad in the short term financials, so we keep babysitting the tower of glass and praying it doesn't fall.

I spent multiple years of my life working on a (at the time I started) decade+ project to retire such a system (i.e. a duct-taped hodgepodge of poorly documented COBOL and mainframe assembler that was understood and maintained by staff who was entering retirement age at an astounding rate), at a "midsize" financial company (i.e. between 3k and 4k employees, all told). While the cost of maintaining the old system was certainly high, it worked astonishingly well (provided you didn't need to add new features, such as a "graphical interface"), and the cost and difficulty in replacing it was truly enormous. I think you're drastically underselling the difficulty of re-implementing a company's entire suite of LOB software, complete with migrations and training, and likely with very little in the way of flexibility to change the core business rules/logic.

Furthermore,

> they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge

Swapping out COBOL for typescript and mainframes for linux boxes and a pile of YAML is not going to change any of that. People can and will build garbage with any set of tools you give them. Not ever software problem is like use-after-free where you can fix it forever with a sufficiently clever piece of tech.

> These systems aren't "survivors" - they're held together with a fragile weave of scripts, hacks, unsupported hardware and outdated knowledge.

It can be, depending on the system and who's complaining about it. Sometimes a fragile, buggy, mess of a legacy system is actually fragile and buggy, with failures causing downtime or lost business, and creaky processes slowing new development to a crawl. Sometimes it's just a system that has an unfamiliar or slightly less ergonomic developer experience, that uses older technologies that some developers don't want to learn. You have to look past the complaints and judge for yourself.

And yet the flip side where companies set piles of cash on fire trying to replace that legacy stuff is also common.

e.g. https://www.computerweekly.com/news/252446965/Lidl-dumps-500...

A reply to myself since I can't edit: Survivorship bias may not completely describe what I'm talking about here but another commenter posted about Lindy Effect, which is 100% on the nose:

https://en.wikipedia.org/wiki/Lindy_effect

These systems are in place and will continue to be maintained simply because they've stood the test of time.

This problem isn't occurring due to software issues.

If they want to pay they'll find someone.

I wouldn't mind taking a 250$ an hour position with on the job training.

Odds are they're getting outbid by easier jobs. If I can write Javascript for 130k or COBOL for 130, I'm doing JS.

You're falling for misdirection. This isn't IT related.

Your comment is being downvoted not because people disagree with you, but because it is not bringing anything constructive to the discussion. Perhaps if you bothered to write about what you think the meltdown really is related to, your commend would have some value.

The original comment from the union only mentioned IT issues from June.

"Our operation and our frontline employees have endured continuous and unending disruptions since the first time our airline made headlines in early June due to widespread IT failures."

That's what makes it misdirection, mentioning an issue from June, and very specifically not talking about a current IT issue. If there were a current issue, they would have called it out. The union has also been pretty clear in other statements that operational issues over the past few months were due to staffing shortages, not IT.