6 ms·
That's a good question! The reason given is it's getting difficult to find COBOL programmers and the platform isn't as agile as other platforms. I have to admi
by taylodl 6y ago
That's a good question!
The reason given is it's getting difficult to find COBOL programmers and the platform isn't as agile as other platforms. I have to admit that IBM is working to make the platform more agile and you can do more than run COBOL - you can run Java and Linux on Z. I've been in IBM training sessions where I've been running Linux on Z and then running Docker on top of that and unless you had told me otherwise the experience was normal: you're running bash, running Docker and everything runs as you'd expect.
BUT - the problem is the core of our system is written in COBOL. There's still CICS, JCL, Copybooks and DB/2 and those who can work with those technologies are now within 10 years of retiring and the new generation doesn't know them or have much of a desire to learn them. Heck, I'm part of the first generation of PC developers from the mid-1980's and I've never done any mainframe development!
The thinking then is we'd better jump off before all these people retire and you end up having to pay $300+/hr for resources capable of working with these legacy technologies. Pay now and buy yourself a new technology set and new capabilities or pay later and just keep the system running.
- xirbeosbwo1234 6y agoWhy ditch the mainframe? It sounds like the software is the problem here, not the hardware.
- OldHand2018 6y ago> 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.
- bluGill 6y agoCompanies 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.
- monocasa 6y agoAnd 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.
- closeparen 6y agoHow 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?
- brendoelfrendo 6y agoYeah, 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.
- lotsofpulp 6y agoA more expensive proposition. Dangle some high six figure salaries and it will also be the new hotness.
- denimnerd42 6y agonah, 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.
- notsureaboutpg 6y agoThis is absolutely untrue. All of my colleagues and friends put up with corporate SV crap the same way they'd put up with bank / insurance company crap only for the pay. If a bank were paying SV salaries to do COBOL programming on a mainframe, I'd jump for it, honestly.
- guenthert 6y agoMight 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).
- rbanffy 6y ago> 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.
- ghaff 6y agoI 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.
- rbanffy 6y agoUnfortunately, banks don't see mainframe-based applications as a competitive differential. If they did, they would invest more heavily on that.
- hakfoo 6y agoI'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.
- 908B64B197 6y ago> 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.
- pjmlp 6y agoThat 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.
- 908B64B197 6y agoTrue, but it's the one that's getting the most attention. It sets the trends and build what's next. RandomBigCo just follows.
- pjmlp 6y agoMost 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.
- worker767424 6y agoNone of the major cloud providers let you lease a mainframe, either.
- eb0la 6y agoA 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.
- ghshephard 6y agoRe: 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.
- throwawayboise 6y ago> 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.
- strongai 6y agoAA?
- hakfoo 6y agoI 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.