8 ms·

As someone who used to work for a Mainframe software vendor I'm tired of COBOL being considered "legacy" and bad. I didn't do much COBOL programming, but IBM is

by jareds 2y ago

As someone who used to work for a Mainframe software vendor I'm tired of COBOL being considered "legacy" and bad. I didn't do much COBOL programming, but IBM is still releasing new compilers and new versions of z/OS for the Mainframe. Just because a language is old doesn't mean it's useless and worth rewriting. Instead of having COBOL be the boogeyman explain what the issues are. Is the system stuck on old COBOL versions do to lack of funding for upgrades, incompetence when it comes to long term maintenance plans, technical issues that make it impossible to move forward with new COBOL versions and would require a rewrite, etc. Are we going to see stories like this in 20 years about some company thinking they should rewrite the Linux Kernel in some new language and throw away all the C code that's been running for decades?

a3w 2y ago
Isn't the hard part of programming the requirements engineering and support after the initial release to customers? Which of the unpaid 60+ workhours/week youths that Elon is sending in will stay on the project after shipping 1.0 ?
- techpineapple 2y ago
  Yeah, I wonder how much tooling their is around the existing app and api's. I remember being on this team managing users in this kinda archaic way using scripts, but the scripts we're really effective, so someone came in and rewrote the whole thing to use LDAP, and like sure it was technically the right choice, but it added like 6 hours per week of overhead because the tooling wasn't there, and, there were no real described tangible benefits other than "lol, bash scripts"
mattlondon 2y ago
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)
breakingrules3 2y ago
[dead]
tbarbugli 2y ago
Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.
- nine_k 2y ago
  Consider legacy: yes. Throw away the codebase: no, until you have a well-working, battle-tested replacement. I mean, yes, it's possible to do, and you can even run e.g. Java under z/OS on the same in-house mainframe hardware because you can't trust the public cloud. But you still have to do the massive work of reverse-engineering the ancient, scantly documented Cobol codebase, write a modern replacement, cover a ton of corner cases, run in in prod as a shadow that does all the same work, and comparing the results with the load-bearing Cobol codebase, and switch over very carefully. Depending on the size of your codebase, the complexity of your processes, the strength of your need for change, and the quality of your engineering org, the above may be a very costly process. Few managers are comfortable to approve such a large cost without a very clear return on this investment. Hence we'll see Cobol running for a few decades more.
arghwhat 2y ago
This misses the point of why COBOL is legacy and bad. Using a language with no real community support and a very small available skilled workforce has massive negative effects on cost and productivity (i.e., the ability to deliver changes at reasonable cost, in reasonable timeframes, and with reasonable success). You don't want to have something that people could be taught to operate, you want something where skill is a commodity and competition is sprawling. COBOL fails on these parameters, and therefore it is "legacy and bad". You can replace COBOL in the above with any language having insufficient contemporary adoption.
- soco 2y ago
  COBOL engineers are about the lowest on the pay grade and steadily deliver (when they are involved). Peanuts compared to any fancy consultant invited to draw cloud architectures with unrealistic expectations or timeframes. So this workforce cost argument does not hold water. However, licenses are very expensive indeed, which is why there are migration pathways for COBOL-on-other-platforms. But a migration is much less sexy than a rewrite (AI supported) so there.
  - arghwhat 2y ago
    The general consensus around here has always been that you can get paid whatever you want if you're willing to code COBOL by being a specialist consultant. This holds true for any legacy system, whether it's a factory control system, a legacy programming language, an ancient piece of hardware or whatever. That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs. "Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.
- _DeadFred_ 2y ago
  There are the same number of COBOL devs and embedded driver devs. Guess we better switch hardware away from using embedded drivers.
_DeadFred_ 2y ago
Much lower hanging fruit than a re-write project would be to go after wage theft and businesses fraudulently not paying into Social Security such as via mis-classification. Not sure why Doge doesn't prioritize that largest offenders/perpetrators of fraud against Social Security, I.E. American business that routinely fraudulently fail to follow the law. Misclassification/taking peoples wages (prevent social security being pay on those taken funds) are larger than the agreed sub 1% of Social Security payments that are fraud. https://en.wikipedia.org/wiki/Misclassification_of_employees_as_independent_contractors https://en.wikipedia.org/wiki/Misclassification_of_employees... https://en.wikipedia.org/wiki/Wage_theft https://en.wikipedia.org/wiki/Wage_theft
- ttyprintk 2y ago
  I’ve got some bad news about the good benefits of donating $2m to the Trump campaign.
bitsandboots 2y ago
I also find it funny that COBOL is treated as the boogeyman. It's just a language. Any programmer by profession should be capable of learning a language decently in a month, and better within the year. So when people say "all the COBOL programmers are retiring!", they're completely missing the problem. The language isn't the problem. The problem is the design of the software written in COBOL, z/OS itself, and the operators that defend its design. The software has so much dark matter due to tech debt, partially due to age, partially due to vintage. z/OS has tech debt, due to designs for a different era being carried forward. Manual processes that should have safety guards and technical limitations abound. But that's not to say DOGE should be trying to rewrite this stuff. Not on their schedule and not with their staff. Because it will create bugs. The same reason this software persists.
was8309 2y ago
cobol is trivial to learn. the problem is that the core of old systems were written even before 'Structured Programming' and anything like reviewing and enforcing design standards. there is alot of 60 year old, currently running 'mission critical' cobol, some of it is inscrutable and unmaintainable, while some of it is so simple and elegant that it'd be a great way to teach a 10 year old about programming.
- cratermoon 2y ago
  COBOL is also missing most of the QOL aspects of modern languages. A COBOL system is closer to a bunch of shell scripts coordinated by a master script than anything we might today think of as modular and componentized. I won't go so far as to say "every variable is global", but it's darn close.

by jareds 2y ago

a3w 2y ago

Isn't the hard part of programming the requirements engineering and support after the initial release to customers? Which of the unpaid 60+ workhours/week youths that Elon is sending in will stay on the project after shipping 1.0 ?

techpineapple 2y ago
Yeah, I wonder how much tooling their is around the existing app and api's. I remember being on this team managing users in this kinda archaic way using scripts, but the scripts we're really effective, so someone came in and rewrote the whole thing to use LDAP, and like sure it was technically the right choice, but it added like 6 hours per week of overhead because the tooling wasn't there, and, there were no real described tangible benefits other than "lol, bash scripts"

mattlondon 2y ago

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)

breakingrules3 2y ago

[dead]

tbarbugli 2y ago

Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.

nine_k 2y ago
Consider legacy: yes. Throw away the codebase: no, until you have a well-working, battle-tested replacement. I mean, yes, it's possible to do, and you can even run e.g. Java under z/OS on the same in-house mainframe hardware because you can't trust the public cloud. But you still have to do the massive work of reverse-engineering the ancient, scantly documented Cobol codebase, write a modern replacement, cover a ton of corner cases, run in in prod as a shadow that does all the same work, and comparing the results with the load-bearing Cobol codebase, and switch over very carefully. Depending on the size of your codebase, the complexity of your processes, the strength of your need for change, and the quality of your engineering org, the above may be a very costly process. Few managers are comfortable to approve such a large cost without a very clear return on this investment. Hence we'll see Cobol running for a few decades more.

arghwhat 2y ago

This misses the point of why COBOL is legacy and bad. Using a language with no real community support and a very small available skilled workforce has massive negative effects on cost and productivity (i.e., the ability to deliver changes at reasonable cost, in reasonable timeframes, and with reasonable success). You don't want to have something that people could be taught to operate, you want something where skill is a commodity and competition is sprawling. COBOL fails on these parameters, and therefore it is "legacy and bad". You can replace COBOL in the above with any language having insufficient contemporary adoption.

soco 2y ago
COBOL engineers are about the lowest on the pay grade and steadily deliver (when they are involved). Peanuts compared to any fancy consultant invited to draw cloud architectures with unrealistic expectations or timeframes. So this workforce cost argument does not hold water. However, licenses are very expensive indeed, which is why there are migration pathways for COBOL-on-other-platforms. But a migration is much less sexy than a rewrite (AI supported) so there.
- arghwhat 2y ago
  The general consensus around here has always been that you can get paid whatever you want if you're willing to code COBOL by being a specialist consultant. This holds true for any legacy system, whether it's a factory control system, a legacy programming language, an ancient piece of hardware or whatever. That workforce is a small retiree club at this point, with financial institutions panicking and trying to promote COBOL and push it into computer science programs. "Steadily deliver" is not a quality you can blanket assign to a group of people, and sounds more like an excuse for poor performance. The only quality one can assign to a small group of people will be lack of competition, which is purely about numbers, although that itself does not mean there won't be good developers in the group - just that that there is a lack of stimuli to grow the baseline.
_DeadFred_ 2y ago
There are the same number of COBOL devs and embedded driver devs. Guess we better switch hardware away from using embedded drivers.

_DeadFred_ 2y ago

Much lower hanging fruit than a re-write project would be to go after wage theft and businesses fraudulently not paying into Social Security such as via mis-classification. Not sure why Doge doesn't prioritize that largest offenders/perpetrators of fraud against Social Security, I.E. American business that routinely fraudulently fail to follow the law. Misclassification/taking peoples wages (prevent social security being pay on those taken funds) are larger than the agreed sub 1% of Social Security payments that are fraud. https://en.wikipedia.org/wiki/Misclassification_of_employees_as_independent_contractors https://en.wikipedia.org/wiki/Misclassification_of_employees... https://en.wikipedia.org/wiki/Wage_theft https://en.wikipedia.org/wiki/Wage_theft

ttyprintk 2y ago
I’ve got some bad news about the good benefits of donating $2m to the Trump campaign.

bitsandboots 2y ago

I also find it funny that COBOL is treated as the boogeyman. It's just a language. Any programmer by profession should be capable of learning a language decently in a month, and better within the year. So when people say "all the COBOL programmers are retiring!", they're completely missing the problem. The language isn't the problem. The problem is the design of the software written in COBOL, z/OS itself, and the operators that defend its design. The software has so much dark matter due to tech debt, partially due to age, partially due to vintage. z/OS has tech debt, due to designs for a different era being carried forward. Manual processes that should have safety guards and technical limitations abound. But that's not to say DOGE should be trying to rewrite this stuff. Not on their schedule and not with their staff. Because it will create bugs. The same reason this software persists.

was8309 2y ago

cobol is trivial to learn. the problem is that the core of old systems were written even before 'Structured Programming' and anything like reviewing and enforcing design standards. there is alot of 60 year old, currently running 'mission critical' cobol, some of it is inscrutable and unmaintainable, while some of it is so simple and elegant that it'd be a great way to teach a 10 year old about programming.

cratermoon 2y ago
COBOL is also missing most of the QOL aspects of modern languages. A COBOL system is closer to a bunch of shell scripts coordinated by a master script than anything we might today think of as modular and componentized. I won't go so far as to say "every variable is global", but it's darn close.