Hacker News Reader

> BUT - the problem is the core of our system is written in COBOL.

This is the key issue. You can migrate it off the mainframe or you can migrate it to sexier tech on the mainframe.

> and the new generation doesn't know them or have much of a desire to learn them.

One of the barriers is that these companies are not willing to pay the same money we (I think we are from the same generation - I was paid to write Apple II software) can get from working with anything that's not COBOL.

I'd love to spend some time with mainframes - they are the fastest Linux machines you can get - but don't want it enough to combine COBOL and JCL with a significant pay cut.

I think that's often the case with "skills shortages."

If banks routinely started paying Google salaries for good COBOL developers, you'd see those shortages disappear in a big hurry.

Unfortunately, banks don't see mainframe-based applications as a competitive differential. If they did, they would invest more heavily on that.

I've always wondered what exactly banks DO see as a competitive advantage. If I want to take my money somewhere, what's the single-slide pitch for why should I choose Chase or Bank of America versus a regional/local competitor?

It's not pricing. As a consumer, it always seemed like the largest banks tended to be relatively non-aggressive on their rates. Isn't "we have economies of scale and pass the savings to you" the classic competitive play?

It's barely, if at all, public facing apps/websites. Okay, you've all got a branded app, you've all started offering Zelle, and you all let me take a photo of the (average of) five paper cheques I recieve in a year to deposit them.

It feels like for a while it was the vague promise of "we've got the largest network so you don't need to worry about finding a machine." A concern largely mooted by smaller banks refunding out-of-network fees and credit union networks.

A depositor is not the customer banks are chasing. It's the businesses who want loans and financial services like M&A and IPOs.

Their competitive advantage is not in their software at all. It's in their relationships. The software helps them scale to large numbers of depositors. That's all.

Yeah, RHEL and SLES have supported mainframe for a long time. Tons of mainframe users are running "modern" software stacks on top of the hardware. You can even do it in parallel with running the legacy stuff (and they do).

>One of the barriers is that these companies are not willing to pay the same money we (I think we are from the same generation - I was paid to write Apple II software) can get from working with anything that's not COBOL.

As a younger person (graduated 2012) who entered the mainframe space for my first job then left after 2y, I can very much vouch that compensation for software devs working on zOS systems writing COBOL or HLASM is peanuts. You'd be looking at 1.5-2x'ing your income even if you took a job at a series A startup writing CRUD apps in Rails/etc.

Perhaps you just need to wait 10 year for everyone to retire and then the market supply will jack up these rates!

There's a good argument for unionizing here. There are few enough COBOL devs that they could demand what they are worth and support it with industrial action.

This will be the fastest method of getting bank software rewritten in rails.

That sounds like the fastest method of getting fiat money replaced with cryptocurrency.

> the new generation doesn't know them or have much of a desire to learn them

On one hand, I'd say that this is true. But on the other, I'm not so sure.

15 years ago, I interviewed for a job that turned out to be for building software on OpenVMS running on Alpha.

I had honestly never heard of either thing.

The interviewer, who would be my manager, said that isn't a problem, it's just a computer that works a little different than others. Do you want to learn it? I said ok.

Over the years, the hiring process changed, and there is no way that someone like me would even be sitting at that interview where they could ask if I wanted to learn.

So companies can go ahead and spend all that money on legacy consultants and all that money on migrating their systems.

Companies that want to hire new people haven't change. If you want a standard web app you can demand someone with experience in the framework of your choice and get it. If you want someone to write in your custom language - you know they have to learn it so you hire people who can learn.

And not even a super custom language. Get out of the bay area and you'll see tons of job postings that ideally want Go or Scala experience, but will gladly teach you if you have the right fundamentals. That's the only way to get their hiring top of funnel large enough to fill seats.

I really think big iron's customer's problems are that they don't want to pay for quality engineers, but for some reason will pay those higher rates or more for some overpriced consultants. Literally just accepting that the outsourcing dream of 2000 was not a great move and using that money on internal engineering would go soooo far. You see even .gov getting the hint with 18F and the US Digital Service building and supporting non contractor government engineers.

Re: The reason given is it's getting difficult to find COBOL programmers

Cobol programming is a skill that is trivially taught. Any student with a Cmpt. Science degree from a credible institution, given a curriculum, can learn any programming language in a month with a bit of focus/appropriate curriculum. Can pick up the necessary frameworks in a reasonable period of time. Then it's just a matter of teaching them the line of business, and the practices and procedures.

I would claim that, given twelve months, you could teach a cohort of recent Cmpt. Science graduates all the skills they needed to be successful in any Insurance/Banking/Finance programing environment.

And these are developers that you can then pay a very reasonable salary - say, $150K/year - which is $75/hour, not $300/hr, at the cost of 1 year of salary as they come on board, come up to speed (say at an out-of-college salary of $100K/year.) - You need 1,000 of those developers - that's an up-front cost of $100mm, at which point you have your developers.

Compared to a multi-billion dollar transition cost off of a mainframe, I know which one I would chose if I were the PHB.

> Cobol programming is a skill that is trivially taught.

And this used to be very common. My first job out of school in the early 1990s was with a "big consulting firm" they had a boot camp where they taught COBOL to batches of new hires. You did that for a month, and then were deployed to a client site writing COBOL about 50 hours a week.

AA?

I wonder if it's less that COBOL is hard and more that there's a lot of design philosophies in legacy codebases that more recently trained developers are going to find frustrating/error prone.

I've done some work in the financial space. It's interesting to compare, for example, expressing a credit card transaction in an ISO 8583 message versus a modern JSON/REST API format. The same data might be there, but one of them is going to be much harder to debug without a lot of specialized tooling.

A lot of mission critical systems are Java on the mainframe. Not just Cobol.

Why don't people switch, then?

The mainframe gives you a predictible runtime. Long running jobs don't get rescheduled or hogged by other loads.

I know about a firm that uses a mainframe to control a factory line.

The problem with replacing stuff that works (and the mainframe does) is then your job is on the line if the transition fails, and there are a lot of business moving parts inside.

How hard is it, really, to learn? Big Tech is constantly hiring people to work in technologies they don't know yet. We were all in on Go before anybody off the street knew it. Facebook has its own language. I'm sure businesses would prefer instant productivity, but is the training expense really bigger than the migration expense?

Yeah, but... can you hire for it? Plenty of forward-looking developers are willing to learn Go, or whatever new hotness the SV scene is cooking up. I think pitching mainframe development to that same crowd is a much harder proposition.

A more expensive proposition. Dangle some high six figure salaries and it will also be the new hotness.

nah, I think both ideas are wrong. that crowd would never want to work for a bank or insurance company in the first place unless desperate. due to their org structure they can never get any real value out of any 1 person, especially an engineer. so that salary will never exist in the first place.

Might not be the same crowd, but some of us wouldn't mind to learn COBOL and get our hands on a mainframe (while at the same time wondering whether the world really needed Go).

The question isn’t how hard it is to learn but who is willing to embrace an old technology which for now it doesn’t even make financial sense. When $300/hour becomes the norm you’ll have plenty of resources. For now COBOL jobs aren’t very attractive

> the new generation doesn't know them or have much of a desire to learn them

No top 50 CS program teaches these tech. No unicorn uses them. Not a single FAANG or FANNG+ if you include other large players.

Finally, no engineering-centric company uses these tech. That's the difference between learning Go vs COBOL.

That is a very tiny employment market.

There are only a couple of FAANG+, with crazy hiring practices, and most businesses aren't engineering centric, the world is bigger than that.

True, but it's the one that's getting the most attention.

It sets the trends and build what's next. RandomBigCo just follows.

Most RandomBigCo just sees any kind of software development as a cost center, and eventually outsources it, to keep their focus on selling their actual products, while some else writes CRUD applications for stock management.

None of the major cloud providers let you lease a mainframe, either.