3 ms·

Might be more prosaic - could just be hard to find COBOL engineers, and the ones they do find might want extortionate rates. Rewriting in something where engin

Might be more prosaic - could just be hard to find COBOL engineers, and the ones they do find might want extortionate rates. Rewriting in something where engineers are cheaper and that can use commodity/cloud servers probably looks quite good on paper Vs paying IBM in blood.

afavour 2y ago
"looks good on paper" So goes almost every project that wants to rewrite a giant legacy system from scratch. In reality the number of developer hours will massively eclipse the price you'd have paid those hard to find COBOL engineers. But doing that would require the DOGE folks to admit that they don't actually know everything and need to defer to someone with more knowledge. So it can't possibly be allowed.
- Frost1x 2y ago
  I can’t say I’ve worked in the COBOL space but it certainly seems like it would be difficult to hire people focused on less transferable tech knowledge. Specialization comes with risk of being phased out and left with your thumb in the wind. Generally people choose technology that’s going to maximize their prospects in terms of employment. Maybe that is specializing in COBOL, systems and tech around it, and higher level abstractions that inevitably come along. For me that seems risky in terms of time investment, even more so in todays market, but I could be very wrong.
- mattlondon 2y ago
  Yeah I agree. This was probably kicked off by someone with power seeing how much IBM were charging for support/consultants etc. "Whaaaa? IBM want how much?" On the other hand while I think it is a bit of a stupid idea to migrate off/rewrite for no reason other than "fuck you IBM", there probably comes a time when it does make sense to migrate - there are often hallmarks of this in old legacy systems where you need to do a LOT of work just to keep things running. Typical examples are: really hard to recruit/retain people who know the technology, difficult to change things where the use-case does something the original designers did not anticipate, decades of tech-debt that makes people scared to change anything, endless patching of security fixes, lots of "glue-work" trying to interface the legacy systems with more modern things (think database drivers, automation tooling etc etc). If it is hard to maintain a legacy system today, its going to be even harder in 10 or 20 years. "If it aint broke don't fix it" is valid, but in IT systems (with endless security vulns, endless changes to data legislation and sovereignty controls etc) you cant stand-still and leave things alone if it is a connected system dealing with people's personal data/finances/health/etc. Somewhere sooner or later you're going to need to pull the trigger and sustain your business by investing in new technology rather than pouring more and more and more money into keeping a legacy system that is no longer fit for purpose. It will hurt sure, but sometimes you have to do it. Just do it carefully and in a realistic way (timelines, testing, slow-migration path etc)
  - afavour 2y ago
    Oh, replacing a legacy system can make sense in a dozen different ways. But you do it carefully, replacing piece by piece and verifying that everything still works. Replacing the whole thing in a couple of months? Doomed. Absolutely doomed.
    - _DeadFred_ 2y ago
      Especially with the deeply dysfunctional dynamic between DOGE and the subject matter experts.
    - cratermoon 2y ago
      > Replacing the whole thing in a couple of months? Doomed. Absolutely doomed. It will make the initial launch of healthcare.gov look like a paradise of puppies and flowers.
hnthrow90348765 2y ago
Something tells me the savings for developer pay and cloud costs vs. COBOL+IBM is going to be invisible on a $14b admin budget (2024)
- mattlondon 2y ago
  > $14b admin budget (2024) Let me introduce you to an IBM salesperson who knows you have no option apart from renew those contracts on the mainframe and COBOL consultants :)
danso 2y ago
This is part of SSA's stated reasoning in their 2017 modernization plan, which asserted the need for a 5-year upgrade process. https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf > Yet, we place extraordinary demands on an installed base of technology that is increasingly showing its age. Most of our core systems are over 30 years old and some embedded software components are older. Over the years, newer technologies have been integrated with these legacy systems without a fundamental redesign of the system and enterprise environment within which it operates. Today, the cost of operating in this legacy environment is expensive. Front- line SSA employees are finding these systems increasingly difficult to use, and members of the public are not getting the self-service opportunities they have come to expect based on their experience with commercial enterprises. Furthermore, systems engineers with legacy system expertise are retiring from SSA at an increasing rate. Replacing them with similarly skilled staff is also increasingly difficult in the current job market.
jareds 2y ago
Then start hiring people at decent pay and provide actual training. This is completely anecdotal but I feel like Mainframe doesn't pay great. I was lucky that i did a lot of work with Java on the mainframe so was able to switch to a non mainframe company and get a significant salary bump. I've also had virtually no interest from recruiters based on my Mainframe experience. I'm not sure if that's because I don't have it front and center on LinkedIn, or if there just isn't a lot of hiring in the Mainframe space? The lack of interest in my Mainframe experience was a thing in 2021 and 2022 as well so I don't think it's related to the current market.
- soco 2y ago
  Because mainframe is "legacy" and also "dusty" technology it won't show in magazines as much as the hype du jour - nosql, frontend wonders, you name it. So yes it will be paid less by default. Also the fact that mostly old folks are maintaining those systems quietly is neither helping their image nor pushing their salaries.
  - browningstreet 2y ago
    Magazines?
kyriakos 2y ago
if you pay me I will learn and write COBOL. I'd write brainfuck if I got paid enough. with programming languages, demand increases supply.

afavour 2y ago

"looks good on paper" So goes almost every project that wants to rewrite a giant legacy system from scratch. In reality the number of developer hours will massively eclipse the price you'd have paid those hard to find COBOL engineers. But doing that would require the DOGE folks to admit that they don't actually know everything and need to defer to someone with more knowledge. So it can't possibly be allowed.

Frost1x 2y ago
I can’t say I’ve worked in the COBOL space but it certainly seems like it would be difficult to hire people focused on less transferable tech knowledge. Specialization comes with risk of being phased out and left with your thumb in the wind. Generally people choose technology that’s going to maximize their prospects in terms of employment. Maybe that is specializing in COBOL, systems and tech around it, and higher level abstractions that inevitably come along. For me that seems risky in terms of time investment, even more so in todays market, but I could be very wrong.
mattlondon 2y ago
Yeah I agree. This was probably kicked off by someone with power seeing how much IBM were charging for support/consultants etc. "Whaaaa? IBM want how much?" On the other hand while I think it is a bit of a stupid idea to migrate off/rewrite for no reason other than "fuck you IBM", there probably comes a time when it does make sense to migrate - there are often hallmarks of this in old legacy systems where you need to do a LOT of work just to keep things running. Typical examples are: really hard to recruit/retain people who know the technology, difficult to change things where the use-case does something the original designers did not anticipate, decades of tech-debt that makes people scared to change anything, endless patching of security fixes, lots of "glue-work" trying to interface the legacy systems with more modern things (think database drivers, automation tooling etc etc). If it is hard to maintain a legacy system today, its going to be even harder in 10 or 20 years. "If it aint broke don't fix it" is valid, but in IT systems (with endless security vulns, endless changes to data legislation and sovereignty controls etc) you cant stand-still and leave things alone if it is a connected system dealing with people's personal data/finances/health/etc. Somewhere sooner or later you're going to need to pull the trigger and sustain your business by investing in new technology rather than pouring more and more and more money into keeping a legacy system that is no longer fit for purpose. It will hurt sure, but sometimes you have to do it. Just do it carefully and in a realistic way (timelines, testing, slow-migration path etc)
- afavour 2y ago
  Oh, replacing a legacy system can make sense in a dozen different ways. But you do it carefully, replacing piece by piece and verifying that everything still works. Replacing the whole thing in a couple of months? Doomed. Absolutely doomed.
  - _DeadFred_ 2y ago
    Especially with the deeply dysfunctional dynamic between DOGE and the subject matter experts.
  - cratermoon 2y ago
    > Replacing the whole thing in a couple of months? Doomed. Absolutely doomed. It will make the initial launch of healthcare.gov look like a paradise of puppies and flowers.

hnthrow90348765 2y ago

Something tells me the savings for developer pay and cloud costs vs. COBOL+IBM is going to be invisible on a $14b admin budget (2024)

mattlondon 2y ago
> $14b admin budget (2024) Let me introduce you to an IBM salesperson who knows you have no option apart from renew those contracts on the mainframe and COBOL consultants :)

danso 2y ago

This is part of SSA's stated reasoning in their 2017 modernization plan, which asserted the need for a 5-year upgrade process. https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf https://www.ssa.gov/open/materials/IT-Modernization-Plan.pdf > Yet, we place extraordinary demands on an installed base of technology that is increasingly showing its age. Most of our core systems are over 30 years old and some embedded software components are older. Over the years, newer technologies have been integrated with these legacy systems without a fundamental redesign of the system and enterprise environment within which it operates. Today, the cost of operating in this legacy environment is expensive. Front- line SSA employees are finding these systems increasingly difficult to use, and members of the public are not getting the self-service opportunities they have come to expect based on their experience with commercial enterprises. Furthermore, systems engineers with legacy system expertise are retiring from SSA at an increasing rate. Replacing them with similarly skilled staff is also increasingly difficult in the current job market.

jareds 2y ago

Then start hiring people at decent pay and provide actual training. This is completely anecdotal but I feel like Mainframe doesn't pay great. I was lucky that i did a lot of work with Java on the mainframe so was able to switch to a non mainframe company and get a significant salary bump. I've also had virtually no interest from recruiters based on my Mainframe experience. I'm not sure if that's because I don't have it front and center on LinkedIn, or if there just isn't a lot of hiring in the Mainframe space? The lack of interest in my Mainframe experience was a thing in 2021 and 2022 as well so I don't think it's related to the current market.

soco 2y ago
Because mainframe is "legacy" and also "dusty" technology it won't show in magazines as much as the hype du jour - nosql, frontend wonders, you name it. So yes it will be paid less by default. Also the fact that mostly old folks are maintaining those systems quietly is neither helping their image nor pushing their salaries.
- browningstreet 2y ago
  Magazines?

kyriakos 2y ago

if you pay me I will learn and write COBOL. I'd write brainfuck if I got paid enough. with programming languages, demand increases supply.