The Coding Language Caught in DOGE's Crosshairs
28:18 Share

On the Media is supported by Progressive Insurance. Do you ever think about switching insurance companies to see if you could save some cash? Progressive makes it easy to see if you could save when you bundle your home and auto policies. Try it at Progressive.com. Progressive Casualty Insurance Company and affiliates. Potential savings will vary. Not available in all states.

Hey podcast listeners, this is Micah. I'm just popping in here before the show starts to share an urgent request.

As I'm sure you know, public media is under threat like never before. We've been covering the nature of these attacks here on the show, and we saw them on full display a couple weeks ago at the House Subcommittee on Delivering on Government Efficiency, when the heads of NPR and PBS defended public broadcasting against accusations by Republican lawmakers of political bias.

This is serious. At a time when public media has never been more valuable, it's also never been more vulnerable.

Thank you.

Giving monthly at the level that's right for you will help us build a strong, lasting foundation to keep this show on air. If you've never chipped in or you want to up your donation, now is the time. To give, go to onthemedia.org slash donate. That's onthemedia.org slash donate. Thank you so much and enjoy the show.

This is the On The Media Midweek Podcast. I'm Brooke Gladstone. Elon Musk's Department of Government Efficiency, or DOGE, has been edged out of the headlines this past week by the administration's current flirtation with a constitutional crisis, among other things. But don't worry, the DOGE team is still hard at work.

The IRS brought in a group of dozens of career IRS engineers, along with two Doge representatives, for a three-day summit hackathon at the IRS building in D.C. Wired's McKenna Kelly this week on CNN. Where they all sat together and planned out this giant project to connect all systems and all data, where someone or a variety of people with special permissions would be able to basically get access to whatever IRS data they sought.

Last month, I reported that DOGE is talking about something similar at the Social Security Administration and wanting to rewrite the Social Security Administration's code base. And these projects are commonly called modernization projects. DOGE has promised a complete rewriting of the agency's computer programs, which handles millions of Americans' personal and financial data.

This left us wondering what the exact meaning of the phrase modernization project is, because much like government efficiency, it's quite and maybe intentionally opaque. For answers to arcane questions about the inner workings of a computer, we like to turn to Clive Thompson, contributing writer to New York Times Magazine and Wired and author of Coders, The Making of a New Tribe and the Remaking of the World.

He says that what lies at the heart of Musk's plan is a decades-old system called COBOL. COBOL is a computer programming language. Banks use it to sort of organize your money. Governments use it to organize anything that has to do with money, like social security or benefits. And the way it came to be was back in the 1950s. There was, you know, the kind of boom of computers being used for the first time in businesses.

It was great for the companies because they could suddenly start to, you know, calculate all sorts of money stuff really rapidly. But the problem with computers back then is that the programming languages were incredibly complicated. They didn't resemble normal written language at all. So a couple of very farsighted programmers, Grace Hopper was one of them, famous early titan of programming, said, this is nuts. We should have a programming language that, A,

Huh.

Stay with Grace for a while. She was a rear admiral in the U.S. Navy, and she is also the person you say who popularized the saying, it's easier to ask forgiveness than permission.

When she created Flomatic, she did it with a few other coders who all happened to be women and who wanted to write, as you say, a language for the computer that looked more like spoken or written English.

Early programming was very, very open to women because back in the early days of computers, the sort of manly heroic thing was in building the hardware. That's where all the guys were. Programming was considered a secondary task and almost kind of secretarial. This goes for several decades until finally there's billions of dollars in software.

money that can come in from making code and the men go, all right, ladies, we'll take over. And that sort of happens in the 70s and the 80s, basically. It took this committee that was working on COBOL 10 years. They were very careful in the way they designed it. For example, because they knew that businesses were going to be using this, they built in

the fact that you could very easily have a decimal point with two numbers after it, which is the way we do financial numbers, right? Like 100.00. Now, this is going to be really nerdy here, but most computer languages make it really difficult to

to very simply and easily place that decimal point right there. You know, you can do it, but it takes some contortions, and those contortions can sometimes create inaccuracies. Now, inaccuracies are fatal, you know, for big business. And so they work that in, and that's one of the reasons why COBOL is still, to this day, really valuable. Because again, you know, all these new modern languages, definitely you can have decimal points. You know, like, they've worked it out. But with COBOL, it was there from the beginning.

When COBOL was rolling out, it was exactly when businesses started to buy up

when companies realized that this was going to be a faster way to manage things. Right, yeah, because we're talking about the late 60s and the early 70s, and it's kind of the big boom for the moment when companies realized we could manage our finances better. We could do predictions. We could kind of model and figure out, you know, what are our sales going to be like over the next 10 years based on what we've learned online?

Where else do you see it?

Well, you see it in other places like, for example, insurance companies. Every time you apply for insurance, there's something called a reconciliation engine. To this day, still using COBOL in many places. You see it in, for a long time, I think they've migrated a bit away from it, but for decades and decades, airlines had COBOL at the backbone of their booking system. So whenever you were buying a plane ticket, they were using COBOL in the background.

And again, you know, large companies that just needed to say manage their sales, you know, how much money is coming in, how much money is going out. So, you know, in the 1990s and really up, I would say, even to the aughts, if you went to like a Home Depot and you saw them typing into a keyboard that was like that kind of green text on a black screen, you know, like hacker stuff.

That's because they were probably talking pretty directly to a COBOL database. They've sort of added layers of dirt on it, and sometimes some of those companies have moved away from it. But you would be surprised how much COBOL is still out there, still kicking around, running a lot of our economic stuff.

It's a badass language. It took 10 years to create, and yet not everyone is a fan. You quote Edgar Dystra, a famed programmer, saying in 1975 that the use of COBOL cripples the mind. Its teaching should therefore be regarded as a criminal offense. Now, what actually is going on there?

Well, he was famous for being a real purist about coding. And he hated any language that made it easy for the everyday person to start coding, right? So he said this about COBOL. And he also said it about BASIC, which is the other very easy-to-use computer language. It opened the doors. It definitely allowed a lot more women into coding. It allowed a lot of working-class people into coding. Like, when I talk to people in the COBOL world,

they would tell you that back in the 70s, you would see these ads just in a local paper saying, hey, we need programmers. If you can sort of pass this BASIC test, we'll train you to come work for our bank, our insurance company, our government agency. And so there was this kind of blue-collar wave of people who got into coding through COBOL and through things like BASIC. And this really just

annoyed, I think culturally, the real high priests of computer science like him. Because it let in the riffraff? Because it let in the riffraff. I mean, I will say he was also correct in that there are elements of languages like COBOL and BASIC that

can allow you to, and perhaps even encourage you to write really ugly code. There's a go-to statement. It's called, if you're in the middle of doing something and you want to zip somewhere else, you say, go to this line. And having written a lot of go-to based code myself in the 80s and basic, I can tell you it's a dangerous ability because you start writing this code that just zips all over the place and it becomes impossible to understand how the heck it works. Definitely,

Plenty of COBOL got written that way. Plenty of BASIC got written that way. He's right that you can write really bad code with it. But there was also definitely a culture war going on.

So, it was loved and hated because it was meant to be intuitive and functioned intuitively. Intuitively and also, here's a key thing, it was meant to be readable. There's a saying inside computer science that a computer program is written primarily for other humans to read and only secondarily for the machine to execute.

Like there is something incredibly crucial about other people being able to look at your code and understand what it does. Because I'm going to write this code for this bank, and then I'm going to die, you know, or I'm going to get hit by a bus or I'm going to retire. And 20 years later, someone's going to need to look at those 5,000 lines I wrote that manage some process. And they're going to have to be able to figure out what that code does. Because if they can't figure out what it does, they can't update it. They can't fix it, right? Right.

And so legibility of code is a really big deal.

Some of this code was written 30 or 40 years ago. And the length of time it's been used by financial institutions is an advantage because the code's been checked and fixed and messed with. And it's very bug free. Right. Whenever you write a piece of code, you sort of try and think through what are people going to do with this? You know, like how are the users going to behave? What are they going to do that I can't really anticipate? And how can I manage for that?

And then you put it out there in the world. And of course, people do even weirder things than you could have imagined. And it starts breaking because you didn't sort of put something in there saying, well, if this person does this odd thing, I know what to do. And after about 15 or 20 years, you know,

The amount of weird things people can do, you've sort of almost covered them all. You know, like there's very few new weird things people are doing. So you have, because the code base is really old, because that COBOL code was written in the 70s and it's now, you know, 40 years later, they have kind of fixed every strange use case. Or maybe they found something they can't fix, but they know how to sort of route around it, right? Like there'll be predictable flaws there.

When I was talking about this, I was reminded of when I have conversations with airline pilots who love flying older planes.

Because anything that is a quirk of that plane is now well understood. You know, people have been flying them for 20 years. So they love sort of a well-lived-in plane where all the good things and all the bad things are really well understood. And so this is one of the reasons why banks look at all this old code and go, well, we're just going to keep with it. But why then, Clive, do they worry so much about the people who created the code and

Getting hit by a bus or dying or retiring because they should be able to intuitively, you know, patch it up the way they have for the last 30, 40 years. The reason why they worry about it is that not a lot of young people are going into COBOL, right? You go to a computer science program today and you're going to be studying a bunch of

Some historic languages that are quite old, like C, C+, some slightly newer ones from the kind of 90s, like JavaScript and Python, some very new ones, like Rust or Go. There is almost nowhere in North America where you will be asked or even offered to take a COBOL course. So the problem the banks have is that the talent pool for people who can come in and know COBOL is drying up.

It's also not enough just to know the way the language works. Like, I mean, I've read the COBOL spec. I've written bits of it. I know how to sort of write COBOL and read it. But what I have no experience doing is sitting down with a database that's managed by COBOL of live financial information with 10 million records and doing something to it and being confident I know what's going on.

Why aren't they training people to do that? You've said that part of the problem is that the...

Young generation doesn't like to be going around fixing things. They'd rather be masters of the universe. You compared it to somebody who knows how to build a house, but they're being asked really to just run around and tighten leaky faucets. Yeah, exactly. I mean, banking and insurance and government have all these systems that are A, mission critical, B, really old, so you don't

don't want to mess with them very much. You want to just fix little stuff. That is very unglamorous work for a coder. A coder likes to do what they call greenfield coding. Here is a whole new field and I'm going to make something new and remarkable in it that's all my own.

it's A, that's fun to do. It's fun to make something new. B, when you make it yourself, you understand every part of it, right? You know, like if I sit down and write a thousand word program, it's, you know, it's complicated, but I wrote it. So I can look back at it now and very quickly understand it. But if I'm a young person,

And I sit down at my job at, you know, Chase Bank. And I've got like, I don't know, 8 million lines of code here or more in the tens of millions. And I've got to start chipping away at little chunks of it, spending months or years just to really fully understand what's going on so that I can do tiny little incremental fixes. I mean, that is just, it might be secure employment, but it's not very exciting employment that drives a lot of young people away from working on these systems.

Which brings us nearly up to the current day. Last month, Wired reported that Doge was planning to rebuild the Social Security Administration's systems in a few months. The SSA's core logic is also written largely in COBOL. That's the code that issues Social Security numbers, manages payments, even calculates the total amount beneficiaries should receive for different services.

And minor changes could result in cascading failures across programs, you were told, by people who are in a position to know. But Doge wants to possibly discard or remake millions of lines of COBOL. Now,

It sounds pretty reasonable because what's wrong with upgrading an old system? Except you argue that part of the motivation here comes from a mistaken belief that because COBOL is old, it's bad. Or really the mythos often discussed on this show that Silicon Valley can always do things better. There isn't Silicon Valley an idea that

All this stuff that was done in the past, particularly government stuff, is inherently inefficient and terrible. And we could do it so much better, faster, and I guess, you know, with better perks and new cool things. And the problem is that, A, again, a lot of this code is actually really good and really fast, does its job really well.

And B, the idea that you could sit down and, you know, in three months figure out everything that this unbelievably complicated Social Security Administration system is doing...

and then replicate it, you know, to rewrite it line by line in a new language is absolutely bonkers. And you've said that banks have thrown millions of dollars at this problem and then ended up backing away. Hundreds of millions, hundreds of millions, absolutely. Give me an example of that. You have banks all over the world that have tried to do this and pretty much failed. I mean, the Bank of New York, Mellon,

I guess about 10 years ago, they realized that they had over 100,000 individual COBOL programs. Like that's just the number of programs. We're talking about millions of lines. And so they were looking at that and they were thinking, you know, wow, we could start chipping away at this, but the potential pain would be so high. There's absolutely no point in even trying it. You know, there are other banks that have actually done it, like the Commonwealth Bank of Australia. They

They had a core language in COBOL, like not all their stuff, just this one area they wanted to redo. They did finally get it done, but it cost them twice as much as they expected. It was $1 billion, Australian dollars. So that's just for one core system. When I talked to people who were conversant in COBOL who have worked in banks, they said, I guess the amount of pain that would be endured trying to rewrite all that stuff is

has made every banker who seriously looked at it just go, forget it. We are never doing this. We're just going to keep on running this COBOL until the sun explodes, basically. And as this guy said, these are banks. They have more money than God. They have no problem throwing money at a problem. And even they are backing away from this, right? Here's a small local version. So the New York Times years ago, I guess about 10 years ago,

they had a COBOL system that managed their delivery, like their paper delivery system. They were like, okay, this is COBOL. It's really old. Let's rewrite this. It took three years, if I'm remembering this correctly, around three years. They wrote a white paper about it because they were so scarred by the experience, almost to sort of warn people away. And they literally just said, this was so much harder than we thought. And this is a comparatively, I mean, it's a complicated system, but compared to a banking system, it's pretty simple. So, you know, there you go.

Another example, one that really made the news in 2020, in New Jersey, its unemployment system crashed and the governor, Phil Murphy, blamed it on COBOL. What happened with the New Jersey system was when COVID first hit, a lot of people went on unemployment. And so everyone was swarming online to the internet to apply for unemployment benefits in every state.

In New Jersey, the system, the website was just crashing and crashing and crashing under the load. And so, of course, this was incredibly embarrassing to the governor. So he holds a press conference and he says, I'm sorry this has been crashing, but we have these really old COBOL systems that just can't handle the load. Everyone sort of accepted that at face value because, again, there's a Silicon Valley idea that new stuff runs fast and old stuff runs poorly.

But in reality, if you talk to anyone who was involved in that work, they'll tell you, no, no, the COBOL systems were absolutely fine. They run fast. They're accustomed to being hit really hard. What broke was stuff in the middle, the actual stuff that manages the web layer, right? Like that was much newer code that had been written really just in recent years. So it was full of bugs and hadn't been optimized yet.

And that's what died. So let's move on to Social Security. Yeah. It's tried to move away from COBOL before. In 2017, the Social Security Administration announced it would seek hundreds of millions in funding to do what Doge says it wants to do now. But the timeline was five years. And the work was put on the back burner by the pandemic.

Why is it so hard to rewrite? Is it because the data it deals with are so complex, like the mountain of numbers a bank has to process every day? Or is it because the code itself, as you described it, though it was designed to be simple, now, because of all the fixes and the patches, looks like a tangled ball of yarn after 40 years of revisions and additions and tweaks?

Yeah, it's more the second thing you mentioned. It's the fact that the code itself is very complicated. And here's the thing, like, it's complicated and it's complicated because it grew over, like, you know, millions of little decisions made over 40 years. So if you wanted to replicate everything that the Social Security system

back-end databases and systems do. You'd have to sit down and go, okay, what are all the thousands or tens of thousands or hundreds of thousands of things that this code does? Like if I ask it to do this, to print someone the amount they've got left on their social security balance, how does it do that? How does it figure out what the overall amount for New Jersey is? How does it figure out all the different things? Each of these abilities is

you have to sit down and write down on a piece of paper and say, okay, here's the spec, here's everything this new code has to do. It has to replicate all these abilities this code has. And then you have to sit down and spec that out in the new language.

It's not impossible to do. It's just very painstaking, which is why you want five years, maybe even 10 years, which is what the Social Security Administration originally thought would be a reasonable timeline, right? Not three months. Frankly, even five years when I heard that they were going to be redoing that whole code base in a new language in five years, that seemed ambitious to me.

Is this like NASA? When you start working on a new space initiative, you don't assume you can do it in three months, the way that Doge is talking about. Well, and to be fair, this isn't even just COBOL. Like,

Any complicated piece of software very frequently blows past its deadline because it's just hard to do hard things, right? Now, here's the thing. I might be making it sound like no one should ever try to rewrite the COBOL backend of the Social Security Administration in a new language. That's not true. I really think eventually the government should do that. There are...

excellent reasons to want to replicate that in a newer language. Among other things, you could attract the new talent pool of people to work on it, but also newer languages allow you to do new things that COBOL makes very, very difficult. You know, before COBOL,

Trump and Doe started shutting them down, there was actually a lot of teams that had been carefully built over the last 10 years around the country that were designed to sort of take young, ambitious, publicly-minded coders and say, okay, we're going to pair you up with a government service that has some crazy old backend system. And we're going to have you try and figure out what sort of stuff can you layer on. Maybe you can't change the stuff at

the bottom of this code. But could you put some stuff on top of it that helps make things better for citizens? And they've done that really, really well. Have they all been fired now? A lot of them are gone. Yeah, these departments are gone. And here's the other thing I'll mention. One of the things that the Doge people, and particularly Elon Musk, are

are very enthralled by now is the idea that in the past, it might have been really hard to rewrite an old code base because you had to do it manually, line by line. But now we have AI, large language model AI, that is actually pretty good at

at a simple level anyway, writing code or helping you understand code. You can give it a piece of code and say, what does this code do? And it explains it to you. And so one of their arguments was, well, we could do this much faster than anyone could in the past because we can now use AI to rewrite the code. That's correct. Those code tools, I mean, I use them. They're great. But what everyone has also been finding as they use these code tools is that

Once a system gets really complicated, the code tools have trouble grasping what's going on, and they start making faulty assumptions about how things link together, or they don't make those assumptions at all. They work great for small little projects. Once you start talking about millions of lines of code, it hasn't really been proven in any significant way that they might be great at something at that scale.

So there's this kind of AI will save us argument floating in behind all this. We're going to rewrite COBOL that I'm unpersuaded by. So what does this argument over COBOL say about the state of our digital world and how it runs our big institutions, both private and public? I think the big takeaway, or what I would hope the big takeaway would be, is that we

A lot of the really big economic systems we have running our economy, both private and public, actually function incredibly well. And they do that because they operate fairly cautiously and they move a little slowly. Instead of move fast and break things, they move slowly and fix things. And there's enormous value in that.

It's not that it isn't good sometimes to try and shake things up, and it's always good to try and modernize things, but we should definitely have a healthy respect for some of the systems that are out there in a very unsung way, thriving and doing a really good job and not breaking. If we don't move cautiously, we break things. Social security checks stop being issued.

People discover they can't figure out what's in their account. You have a really serious breakdown in an absolutely core piece of the American economy. I actually think there would be massive political backlash to that. It may be one of the reasons why Doge is sort of soft-pedaling or not talking so much about its plans for COBOL anymore. This is the one thing that if you really wrecked it, you know, there would be hell to pay. Clive, thank you very much.

I had a good time, and I will come any time to talk about cobalt at length. This is not something that happens a lot in my journalistic life. Clive Thompson is the author of Coders, The Making of a New Tribe and the Remaking of the World. Tune in on Friday for the big show. This week, Micah and I immerse ourselves in nothing but right-wing media for 12 hours and report back on what we've learned. See you then. I'm Brooke Gladstone.

This is Ira Flato, host of Science Friday. For over 30 years, the Science Friday team has been reporting high-quality science and technology news, making science fun for curious people by covering everything from the outer reaches of space to the rapidly changing world of AI to the tiniest microbes in our bodies.

Audiences trust our show because they know we're driven by a mission to inform and serve listeners first and foremost. With important news, they won't get anywhere else. And our sponsors benefit from that halo effect. For more information on becoming a sponsor, visit sponsorship.wnyc.org.