I think Cobol programmers get $60k in Austin, which is about $20k a year less than the lowest paid Java developer gets in the area, so I would guess that the shortage is a result of low pay. Also, Cobol depends on a lot of institutional knowledge since they are not likely to be building greenfield systems. This would make it hard for someone who knew the Cobol language to really know what the system they are programming on does and get started extending its usage. And it seems like the less a programmer is paid, the less patience management has with them.

MARK IV is the oldest language in use that I know of that I have personally had contact with, and I've had contact with it recently. I would say that the issue isn't just finding Cobol programmers, but a mix of mainframe specific languages and technologies no longer in wide use outside of mainframes' data warehouse solutions, such as DB2 and VSAM.

The main problem with Cobol, REXX, JCL and MARK IV is that the solutions/problems encountered cannot just be google'd through stackoverflow or some online forum. Institutional knowledge from 30 year experienced self-starters or solution specific candidates with 30 years of experience in a piece of the project needing assistance who is willing to be a self-starter for gaining experience enough in the other technologies the mainframe uses.

> I think Cobol programmers get $60k in Austin, which is about $20k a year less than the lowest paid Java developer gets in the area

On top of that they tend to be stodgy old corporate companies that developers hate, where you have to wear a suit to work and being seated by 9AM is more important than doing your job well. Then there's the fact that it could be career suicide to spend so long on tech that fewer and fewer companies are using. And you'll need an exit plan because it's used at become companies that do regular mass layoffs, they've probably fired more cobol programmers than they'll ever need. They should be paying a hefty premium to get people.

The language itself and surrounding systems can't be any worse than the standard enterprise XML DSL rubbish can it?

>On top of that they tend to be stodgy old corporate companies that developers hate, where you have to wear a suit to work and being seated by 9AM is more important than doing your job well.

That I can attest happens, less so today but then such places lost most of their talent as those that could and able to move on did and those that didn't, well they would of been close to retiring and with that. Hence technical debt increases. But it's not just knowing the COBOL, it's not just knowing that business logic, but how the two go together - THAT level of knowledge was always undervalued in many institutions alas.

The language itself and some of the tooling might be quaint, but I feel that sometimes it's also much simpler than the replacements from turn of the century. Not all corps are stodgy ones, but that's usually contractors that have few COBOL experts, sometimes just to check over work of other contractors. Some vendors are worse than others, some better.

Train them. We do it all the time with new hires or old pals for any mainstream or not language. I saw teams do marvels in a quarter in completely new languages, no matter how far the paradigm. Not claiming COBOL is easy (no idea) but can't be an impossible task. Is probably harder to keep people engaged

From what I understand talking to someone who gets paid enormous amounts of money to occasionally update COBOL systems in heavy industry, working on COBOL is drudgery.

It might be difficult to find a substantial number of people who actually want to be trained in COBOL.

There are a lot of developers who would like to be paid enormous amounts of money. I wonder if the public sector pays well enough to generate the desire to learn, though.

I myself can handle a lot of drudgery for $350k a year.

100% the money is the issue.

So is Java, and my last stint with Python definitely feels drudge-like too. Offer enough real money and appropriately structured career path (especially one that doesn't lead someone down path of "one language programmer") and you might find a team fast.

COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code.

Good developers - those who like what they do - won't touch it with a stick. People do OCaml, Haskell, Clojure in their spare time and C# and Java at work - but nobody codes COBOL in their spare time. People code in Assembly, sometimes in hand-assembled hexadecimal format, but not COBOL.

It's a job, usually a boring one.

I think good developers don't really care so much about which language they work with, but rather care about solving interesting problems.

The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal.

I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense.

It also just so happens to be written in COBOL.

There are different kinds of developers. Some like solving problems and wouldn’t be bothered by COBOL. Others are more aesthetically motivated.

https://blog.carlmjohnson.net/post/2017/what-kind-of-program...

> COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code.

THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP.

But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.