Social Security systems contain tens of millions of lines of code written in COBOL, an archaic programming language. Safely rewriting that code would take years—DOGE wants it done in months.
Java can be pretty damn efficient for long running processes because it optimizes at runtime. It also can use new hardware features (like cpu instructions) without having to compile for specific platforms so in practice it gets a boost there. Honestly, the worst thing about Java is the weird corporate ecosystem that produces factoryfactory and other overengineered esoteric weirdness. It can also do FFI with anything that can bind via c ABI so if some part of the program needed some hand optimized code like something from BLAS it could be done that way.
All that to say it doesn’t matter what language they use anyway, because rewriting from scratch with a short timeline is an insane thing to do that never works.
Why is there a need to rewrite it at all? Is it because COBOL is basically ancient hieroglyphics to modern programmers thus making it hard to maintain or update?
They want to make buttloads of money from a rewrite, and it would cost buttloads to do this. They probably also want things to run like shit and cause misery for retired Americans.
Refactoring a code base is kinda like general maintenance for the application. Over time deprecated features, temp fixes, etc. start to be a lot of the code base. By cleaning things up you can make it more maintainable, efficient, etc.
That being said, for systems this large you usually fix up parts of it and iterate over time. Trying to do the whole code base is hard cause it’s like replacing the engine while the car is in motion.
COBOL code, like any code, was written to embody certain business processes, and also to work around the quirks and blind spots of COBOL. And the people who understood those business processes are likely to be dead by now, and any documentation they wrote might be current and correct, or it might not. And very few people under the age of 60 have ever used COBOL in anger. So any legacy replacement project is going to have to encompass a big reverse-engineering effort, including analysis of a code base nobody is familiar with.
I’m old. A friend of mine is a fair bit older, getting into his late 70s. He knows COBOL but his main area of expertise is OS services, database tuning and assembler on old IBM and Fujitsu iron. Those are critical to keeping those old systems running well. He works half-time, is booked over a year out, and has a jaw-dropping daily rate. He also has a rider: one provision is that they have to tell him where he can smoke on-site, and if the answer is “nowhere,” the deal is off. Also, he won’t schedule any work that conficts with Burning Man, and he looks like a homeless guy. I brought him in on a consulting gig once. He did his bit, including an amazingly effective presentation to the C-levels (despite his profoundly non-executive appearance), and went his merry way. Saved us a fortune. You need people like that in order to have even a remote chance of success, and they’re becoming exceedingly rare. Musk and his kiddies don’t even know what they don’t know.
I wouldn’t necessarily agree it needs to be rewritten. Hiring programmers that are willing to work in cobol would certainly be harder than other languages though, because you’ll have a much smaller candidate pool and people would be unlikely to see learning cobol as a good career investment
COBOL is the career advise you hear people give for people who want to make money but don’t want to deal with the VC clownshow. COBOL btw is only 13 years older than C and both language’s current standard dates to 2023.
It’s at its core a bog-standard procedural language, with some special builtins making it particularly suited to do mainframe stuff. Learning COBOL is no worse a career investment than learning ABAP, or any other language of the bureaucracy. Sure you’ll be a career bureaucrat but that’s up sufficiently many people’s alley, no “move fast and break things”, it’s “move slowly and keep things running”.
The language isn’t the problem with COBOL, it’s the likelihood that you will be maintaining (not adding to, but maintaining) a software system that may not have any docs and the original implementers are dead. Next, there will be nobody to verify the business rules that are specified in the code. Finally after you make a mistake about a business rule, you will be thrown under the bus.
Well, the other thing about COBOL is that most people would regard it as a living death to have to deal with it as a day job.
And I’ve had interactions with offshore COBOL shops. The ones I worked with were not at all good. You’ll never get 99th-percentile coders to work in that language, unless their only motivation is money.
Everything that you said is correct, except the prevalence of the career advice. I would bet most people looking for their first job out of school don’t even know COBOL is a language.
The attractiveness of learning it was that you could avoid boom and bus cycles of retrenchment and clowns like Elon musk. Unfortunately that isn’t true anymore so I think once the dust settles, finding people willing to specialize in tech like this is going to get real hard.
Is that true everywhere or just in the US? I know that, at least a few years ago, a bunch of banking software in the US was still in COBOL but parts of Western Europe were modernizing their banking industry. I’m probably going back to school for computer science in the fall and had been considering trying to learn COBOL in my free time, or learning more Fortran (I have actually taken a programming class with Fortran, but because it was aimed at beginners it didn’t really go in depth, but I bet it’d look good on certain resumes). It’s looking like my future is in Europe somewhere, so I’m keeping that in the back of my mind while making decisions.
I’m not enough into that industry to actually give a good estimate, here, but the amount of COBOL systems still up and running is certainly not even close to non-zero, and it’s going to stay that way for a while. From what I gather for companies moving away from COBOL is more of a “programmers are hard to find” situation, not “these systems absolutely must be replaced” one. It’s well-supported and scaled with their business, as in, in places they’re running the same 60 year old code on new mainframes because if there’s one thing that IBM mainframes are then it’s excessively backwards-compatible.
As far as the language is concerned: It’s not hard, it’s just weird, dating back from an age where people thought randomly calling things “divisions” would make businesspeople capable coders. The reason I’m not in that space isn’t because of the language but because of the type of software you write there, it’s all bookkeeping and representing business procedures, as said: Bureaucracy.
Also I’m not sure what “modernising” actually meant, there: SEPA instant payment was introduced, meaning that mainframes won’t batch up the day’s transactions and then talk to each other every night so cross-bank transfers took a day to process, now they’re doing it in ten seconds. Most banks already supported instant transfers within their own systems so they should only have had to rewrite the external interface as the rest was already up to the task.
Yeah, Java can run maybe half as fast as equivalently complex C, while being far more maintainable. But to see that kind of performance, you’ll want to use POJOs (plain old Java objects), not that enterprise bullshit. And there are many other optimization techniques that your average Java coder wouldn’t see in their average coding job. I’ve been there, didn’t like it. If I’m going to be dropping down to C for the hot spots, I’d rather use Python.
All that to say it doesn’t matter what language they use anyway, because rewriting from scratch with a short timeline is an insane thing to do that never works.
Schedule-driven development by people with no domain knowledge, with poorly understood requirements and life-and-limb-critical outcomes, led by an unpredictable moron. What could go wrong?
Java can be pretty damn efficient for long running processes because it optimizes at runtime. It also can use new hardware features (like cpu instructions) without having to compile for specific platforms so in practice it gets a boost there. Honestly, the worst thing about Java is the weird corporate ecosystem that produces factoryfactory and other overengineered esoteric weirdness. It can also do FFI with anything that can bind via c ABI so if some part of the program needed some hand optimized code like something from BLAS it could be done that way.
All that to say it doesn’t matter what language they use anyway, because rewriting from scratch with a short timeline is an insane thing to do that never works.
Why is there a need to rewrite it at all? Is it because COBOL is basically ancient hieroglyphics to modern programmers thus making it hard to maintain or update?
They want to make buttloads of money from a rewrite, and it would cost buttloads to do this. They probably also want things to run like shit and cause misery for retired Americans.
Refactoring a code base is kinda like general maintenance for the application. Over time deprecated features, temp fixes, etc. start to be a lot of the code base. By cleaning things up you can make it more maintainable, efficient, etc.
That being said, for systems this large you usually fix up parts of it and iterate over time. Trying to do the whole code base is hard cause it’s like replacing the engine while the car is in motion.
refactor is one thing, rewrite everything in a new language is another thing.
Yet it’s the thing every junior dev wants to do as they gain more experience.
Right after they write yet another content management system.
Oh yeah, definitely.
COBOL code, like any code, was written to embody certain business processes, and also to work around the quirks and blind spots of COBOL. And the people who understood those business processes are likely to be dead by now, and any documentation they wrote might be current and correct, or it might not. And very few people under the age of 60 have ever used COBOL in anger. So any legacy replacement project is going to have to encompass a big reverse-engineering effort, including analysis of a code base nobody is familiar with.
I’m old. A friend of mine is a fair bit older, getting into his late 70s. He knows COBOL but his main area of expertise is OS services, database tuning and assembler on old IBM and Fujitsu iron. Those are critical to keeping those old systems running well. He works half-time, is booked over a year out, and has a jaw-dropping daily rate. He also has a rider: one provision is that they have to tell him where he can smoke on-site, and if the answer is “nowhere,” the deal is off. Also, he won’t schedule any work that conficts with Burning Man, and he looks like a homeless guy. I brought him in on a consulting gig once. He did his bit, including an amazingly effective presentation to the C-levels (despite his profoundly non-executive appearance), and went his merry way. Saved us a fortune. You need people like that in order to have even a remote chance of success, and they’re becoming exceedingly rare. Musk and his kiddies don’t even know what they don’t know.
I wouldn’t necessarily agree it needs to be rewritten. Hiring programmers that are willing to work in cobol would certainly be harder than other languages though, because you’ll have a much smaller candidate pool and people would be unlikely to see learning cobol as a good career investment
COBOL is the career advise you hear people give for people who want to make money but don’t want to deal with the VC clownshow. COBOL btw is only 13 years older than C and both language’s current standard dates to 2023.
It’s at its core a bog-standard procedural language, with some special builtins making it particularly suited to do mainframe stuff. Learning COBOL is no worse a career investment than learning ABAP, or any other language of the bureaucracy. Sure you’ll be a career bureaucrat but that’s up sufficiently many people’s alley, no “move fast and break things”, it’s “move slowly and keep things running”.
The language isn’t the problem with COBOL, it’s the likelihood that you will be maintaining (not adding to, but maintaining) a software system that may not have any docs and the original implementers are dead. Next, there will be nobody to verify the business rules that are specified in the code. Finally after you make a mistake about a business rule, you will be thrown under the bus.
Well, the other thing about COBOL is that most people would regard it as a living death to have to deal with it as a day job.
And I’ve had interactions with offshore COBOL shops. The ones I worked with were not at all good. You’ll never get 99th-percentile coders to work in that language, unless their only motivation is money.
Everything that you said is correct, except the prevalence of the career advice. I would bet most people looking for their first job out of school don’t even know COBOL is a language.
The attractiveness of learning it was that you could avoid boom and bus cycles of retrenchment and clowns like Elon musk. Unfortunately that isn’t true anymore so I think once the dust settles, finding people willing to specialize in tech like this is going to get real hard.
Is that true everywhere or just in the US? I know that, at least a few years ago, a bunch of banking software in the US was still in COBOL but parts of Western Europe were modernizing their banking industry. I’m probably going back to school for computer science in the fall and had been considering trying to learn COBOL in my free time, or learning more Fortran (I have actually taken a programming class with Fortran, but because it was aimed at beginners it didn’t really go in depth, but I bet it’d look good on certain resumes). It’s looking like my future is in Europe somewhere, so I’m keeping that in the back of my mind while making decisions.
I’m not enough into that industry to actually give a good estimate, here, but the amount of COBOL systems still up and running is certainly not even close to non-zero, and it’s going to stay that way for a while. From what I gather for companies moving away from COBOL is more of a “programmers are hard to find” situation, not “these systems absolutely must be replaced” one. It’s well-supported and scaled with their business, as in, in places they’re running the same 60 year old code on new mainframes because if there’s one thing that IBM mainframes are then it’s excessively backwards-compatible.
As far as the language is concerned: It’s not hard, it’s just weird, dating back from an age where people thought randomly calling things “divisions” would make businesspeople capable coders. The reason I’m not in that space isn’t because of the language but because of the type of software you write there, it’s all bookkeeping and representing business procedures, as said: Bureaucracy.
Also I’m not sure what “modernising” actually meant, there: SEPA instant payment was introduced, meaning that mainframes won’t batch up the day’s transactions and then talk to each other every night so cross-bank transfers took a day to process, now they’re doing it in ten seconds. Most banks already supported instant transfers within their own systems so they should only have had to rewrite the external interface as the rest was already up to the task.
Yeah, Java can run maybe half as fast as equivalently complex C, while being far more maintainable. But to see that kind of performance, you’ll want to use POJOs (plain old Java objects), not that enterprise bullshit. And there are many other optimization techniques that your average Java coder wouldn’t see in their average coding job. I’ve been there, didn’t like it. If I’m going to be dropping down to C for the hot spots, I’d rather use Python.
Schedule-driven development by people with no domain knowledge, with poorly understood requirements and life-and-limb-critical outcomes, led by an unpredictable moron. What could go wrong?
I wouldn’t assume that Java is only half as fast as C for every workload. It’s probably a lot closer than you think in a lot of real world scenarios.