Every weeknight, somewhere around 11 p.m. Eastern, a batch job kicks off at a bank you've almost certainly used. It reconciles the day's transactions, settles accounts, flags exceptions, and generates the reports that let the next business day begin. The code doing this was largely written before the programmers running it were born. It still observes line lengths dictated by the physical dimensions of a punch card that stopped being manufactured in the 1980s.1 And it processes roughly $3 trillion in daily commerce.2
The person who keeps that code running is, statistically, fifty-five years old and part of a workforce losing ten percent of its members to retirement every year.3 We wanted to talk to that person.
Dot Babbage is a fictional composite, but her circumstances are drawn from documented accounts of real COBOL practitioners, including Dirk Frobese of Akkodis, whose thirty-year career in banking-sector software development provides the most detailed public record of what this work actually looks like.4 If Dot's name rings a bell from a nineteenth-century computing lecture, she'd appreciate that you noticed.
You've been at the same bank for thirty-four years. What does a normal day look like?
Dot: There's no normal day. There's a normal night. The batch window opens, the jobs run, and if everything works, nobody calls me. I've had stretches where the most visible thing I do all week is answer an email about a report format. Meanwhile, the system settled four hundred million transactions overnight without a hiccup. My best work is when nothing happens. Which is a terrible thing to put on a performance review, by the way.
The code you maintain still uses the column format from punch cards. Columns 1 through 6 for sequence numbers, column 7 for indicators, seventy-two characters for your actual program. Does that ever strike you as absurd?
Dot: Every single day. And also never.
The card is gone, obviously. But the format enforced discipline. Seventy-two characters to work with, and that constraint made people write tight, readable code. I've reviewed modern codebases where a single function sprawls across three screens and still needs a comment block explaining what it does. My COBOL paragraphs fit on a card. There's something to that.
But yes. If you told someone outside this building that trillions of dollars flow through code formatted for a piece of cardboard from 1928, they'd assume you were doing a bit.5
There's a technical argument you make about why COBOL specifically is right for financial systems.
Dot: Decimal precision. Full stop.
Money is not floating point. When you represent ten cents in a language that uses binary floating point — Java, Python, take your pick — you get an approximation. Very close. Impressively close. But across a hundred million transactions, "impressively close" is a rounding error that becomes real money. COBOL was built from the ground up to do exact decimal arithmetic.6 It doesn't approximate. It doesn't round and hope.
Every Java wrapper, every API layer, every microservice sitting on top of my batch system talking to a mobile app — at the bottom, when the actual money moves, it hits COBOL. Because COBOL gets the math right.
People frame this as inertia. Like we just haven't gotten around to it. But every replacement attempt eventually discovers the same thing: you need exact decimal math for money, and the system that already does exact decimal math for money has been sitting right there, running fine, since before the replacement team was hired.
Dirk Frobese, a banking software manager at Akkodis, described how his team built Java interfaces on top of COBOL in the nineties, and then management lost all incentive to replace the mainframe because the new UI looked modern enough. Does that match your experience?
Dot: That's my entire career compressed into two sentences.
I've lived through at least five major modernization initiatives. The pattern never varies. Someone new arrives, sees the green screens, has a small crisis. A project gets funded. Consultants materialize. They build a beautiful front end and connect it to my batch system, because that's where the data lives and that's where the transactions settle. The front end ships. Everyone celebrates. The press release says "digital transformation."4
Underneath, my COBOL is still running. Now it's just running behind a nicer curtain.
The irony is that the invisibility keeps me employed and keeps my budget at zero. Hard to get investment for something nobody knows exists.
In 2020, when pandemic unemployment claims overwhelmed state systems, governors went on national television asking for COBOL programmers. What was that moment like?
Dot: My daughter texted me the clip of Governor Murphy. She said, "Mom, your thing is on the news." Thirty years of my life. My thing.
It was vindicating and humiliating in the same breath. The only reason COBOL made the news was that people thought it was a punchline. "Can you believe they're still using this?" Yes. I can believe it. I've been here the whole time.7
The current AI modernization wave — tools that can analyze, document, and translate COBOL into modern languages. Does this one feel different?
Dot: They always feel different. Java felt different. Cloud felt different. The track record is that roughly seventy percent of modernization projects fail.8 That's the industry's number, not mine. I've just watched it play out repeatedly, in person, with catering.
The AI tools are genuinely good at documenting what the code does, and honestly, that's useful. The documentation for half my codebase was written during the Reagan administration. But translating? You're not translating code. You're translating thirty years of business logic, exception handling, edge cases that exist because in 2003 a specific client did a specific weird thing and we wrote a patch at 2 a.m. That context lives in my head. And in the heads of people who are retiring at ten percent a year.
There's a program called "Kings of COBOL" that recruits retired programmers back for premium freelance work. What do you make of that?
Dot: The pay is terrific. The name is a little much. But it tells you everything about where we are. The skills got so rare that retirement became a negotiating position. I have colleagues who retired, got bored, came back at twice their old salary. The market finally values what we do. It only took everyone else leaving first.3
What do you want people to understand about this work?
Dot: That the code endures because it was right about what mattered. Every time someone tried to replace it, they rediscovered why it was there. And that the person maintaining it isn't a fossil. She's a load-bearing wall.
Footnotes
-
IBM, "What Is COBOL?" — https://www.ibm.com/think/topics/cobol ↩
-
Maintec, "The Power of COBOL: Why It's Still Essential in Modern Mainframe Systems," November 2024 — https://maintec.com/the-power-of-cobol-why-its-still-essential-in-modern-mainframe-systems/ ↩
-
Futurum Group, "2024 Global Mainframe Skills Report," 2024 ↩ ↩2
-
Akkodis, "The Mainframe is Dead, Long Live the Mainframe" — https://www.akkodis.com/en/blog/articles/the-mainframe-is-dead-long-live-the-mainframe ↩ ↩2
-
The Hollerith punch card format, standardized by IBM in 1928, established the 80-column layout that COBOL's source format inherited. Many production COBOL environments still enforce this column structure. ↩
-
IBM, "What Is COBOL?" — https://www.ibm.com/think/topics/cobol. COBOL's native packed-decimal and display-numeric data types perform exact decimal arithmetic, avoiding the rounding errors inherent in binary floating-point representations. ↩
-
Reuters and NPR reported extensively on state unemployment system failures in April 2020, including New Jersey Governor Phil Murphy's public appeal for COBOL programmers. ↩
-
Metaintro, "AI Can Now Modernize Legacy Software," 2026, corroborated by IBM modernization documentation. ↩