Latest / The Productivity Podcast with Fexingo: Output, Efficiency, and Long-Term Economic Growth / The Hidden Productivity Tax of Legacy Software
Transcript
- Lucas: If you walk through the average corporate office today, the loudest sound isn't the phone ringing or the coffee machine grinding. It's the quiet frustration of an employee staring at a screen, clicking through five different menus just to print a single report that used to take three clicks in twenty-nineteen. Luna: Right, and that friction is where the real economic leakage happens. It's not just annoying; it's costing billions in lost output every year. Lucas: Exactly. We talk a lot about AI and automation as the future of productivity, but we rarely discuss the past dragging us down. Today, I want to look at what economists call the productivity tax of legacy systems. Specifically, the hidden cost of maintaining software architectures that were built for a world that no longer exists. Luna: So you're arguing that our current growth stagnation isn't just about bad policy, but about digital hoarding? Keeping old tools alive because they're familiar? Lucas: It's more than familiarity. It's structural inertia. Let's look at the United Kingdom's Driver and Vehicle Licensing Agency. For years, they relied on a core mainframe system written in COBOL, a programming language from the nineteen-sixties. When they tried to digitize services, the old system couldn't handle the data volume without crashing, forcing staff to manually input information that should have been automated. Luna: That sounds like a nightmare scenario. How much time did those workers actually lose doing that manual entry? Lucas: Reports suggested that during peak periods, nearly forty percent of their processing capacity was consumed by workarounds rather than actual service delivery. That is a direct hit to public sector productivity. And this isn't unique to government. Look at the banking sector. Luna: Banks are the classic example of legacy debt. They run on code that predates the internet. Lucas: Precisely. Many major financial institutions still rely on batch-processing systems that only update overnight. This means that when a customer wants to check their balance or approve a transaction in real-time, the system either delays it or requires a human intermediary to verify the data against the older ledger. Every one of those intermediaries is a cost center that adds zero value to the customer experience. Luna: But surely migrating away from that is expensive? Why don't they just rip it out and replace it with modern cloud-native solutions immediately? Lucas: That is the million-dollar question, and it's where the economics get tricky. The cost of migration is high, yes, but the cost of staying put is compounding. Each year you delay, the skill set required to maintain the old system shrinks. You're left with fewer engineers who understand the code, driving up wages for the few who do know it. It becomes a monopoly of knowledge that stifles innovation. Luna: So it's a talent bottleneck as much as a technical one. You can't innovate if your best minds are busy keeping the lights on in the basement. Lucas: Spot on. And here is the counter-intuitive part: many companies try to patch the legacy system with new front-end interfaces. They build a shiny app on top of a crumbling database. But that creates what we call integration debt. Now you have to maintain two systems simultaneously, syncing data between them. The complexity doubles, and the error rate spikes. Luna: That makes sense. It's like putting a new coat of paint on a house with a failing foundation. You think you've solved the problem, but you've just made the underlying rot harder to see. Lucas: Perfect analogy. And the errors aren't just cosmetic. In healthcare, legacy electronic medical records that don't talk to each other force nurses to re-enter patient data. Studies have shown this increases the risk of medication errors significantly. So the productivity loss isn't just slower workflows; it's actual safety risks. Luna: Wow. I hadn't thought about the safety angle. That shifts it from an annoyance to a liability issue. Lucas: It does. Which brings me to the donation segment. If walking through the economy with us has made something click... Luna: Yeah, support keeps these deep dives possible without turning into ad-reads. Lucas: Quick honest thing — a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making this many of these. No ads, just us talking shop. Luna: It really helps keep the research rigorous and the tone conversational. Thanks for considering it. Lucas: Back to the tech debt. So if patching is dangerous and doing nothing is fatal, what is the right path? The standard advice is 'lift and shift'—move everything to the cloud unchanged. But that just gives you a more expensive version of the same old problems. Luna: So you're suggesting that moving to the cloud doesn't solve the productivity problem unless you also refactor the code underneath? Lucas: Exactly. Refactoring is the hard part. It means rewriting the core logic to be modular and scalable. It requires significant upfront investment and temporary disruption. But the long-term gain is agility. A refactored system can adapt to market changes in weeks rather than months. Luna: That sounds like a massive cultural shift too. You're asking leadership to accept short-term pain for long-term gain, which is hard in quarterly earnings cycles. Lucas: Very true. Most CEOs are judged on quarterly results. Refactoring looks like a cost center in the short term. It doesn't generate revenue; it prevents losses. And losses are invisible until they become crises. So the incentive structure is misaligned with what's actually good for the company's long-term health. Luna: It's a classic principal-agent problem. The manager wants the quick win, but the owner needs the sustainable asset. How do companies measure the ROI of fixing legacy code? Lucas: They shouldn't measure it in dollars saved directly, but in velocity gained. How many new features can you ship per month? How fast can you respond to a competitor's move? One manufacturing firm we looked at refactored their supply chain software. After six months of heavy coding, their order to delivery time dropped by thirty percent. That's not just efficiency; that's competitive advantage. Luna: Thirty percent is huge. That would definitely show up in the bottom line within a quarter. Lucas: It does. But getting there required accepting that the first year would be messy. Teams had to work on both old and new systems. Morale dipped initially because everyone felt like they were fighting two wars. Leadership had to protect the team from pressure to deliver new features on the old platform. Luna: That's the key. Protecting the team. If you let them switch back to the old way when things get stressful, you never finish the transition. Lucas: Absolutely. It requires discipline. And it requires a clear endpoint. You can't refactor forever. You need a sunset date for the legacy system. Once that date hits, the old system is shut down, no matter how comfortable people are with it. Luna: Harsh, but necessary. Like closing a store once the lease ends. Lucas: Exactly. And then you start building on the new foundation. What's interesting is that this applies beyond big corporations. Small businesses using outdated inventory software face the same issues. They might not have millions to spend on refactoring, but they can use modern APIs to connect simple tools, avoiding the monolithic trap entirely. Luna: So the lesson is: start small, stay modular, and avoid the black box. Don't buy a giant all-in-one solution that locks you in. Lucas: Right. Modularity is the antidote to legacy debt. If one piece breaks or needs updating, you can swap it out without taking down the whole operation. That resilience is what drives true productivity. Luna: It reminds me of the difference between a custom-built car and a mass-produced one. The custom one is easier to tweak, even if it takes longer to build initially. Lucas: A great comparison. Mass production wins on scale, but customization wins on adaptability. In a fast-moving economy, adaptability is the higher currency. Luna: Do you think AI will accelerate this shift? Can AI help us rewrite legacy code faster? Lucas: AI is already helping. Tools exist that can analyze old COBOL code and suggest modern Python or Java equivalents. It speeds up the translation process. But AI cannot make the strategic decision of what to change. It can translate syntax, but it doesn't understand the business logic behind why a certain workflow exists. That human judgment is still essential. Luna: So AI is the tool, but the architect is still human. We can't automate the decision to stop using broken tools. Lucas: Correct. Automation amplifies whatever system it's attached to. If you automate a bad process, you just get bad results faster. The first step is always fixing the process, then automating it. Luna: Fix before you automate. That's a rule worth remembering. Lucas: It is. As we look toward the next decade, the companies that thrive won't be the ones with the flashiest new apps. They'll be the ones that quietly fixed their foundations. They'll be the ones that stopped paying the productivity tax. Luna: So the quietest companies might actually be the most productive. Is that the ultimate paradox of modern business? Lucas: Maybe. Or maybe it's just common sense disguised as complexity. Either way, it's a reminder that growth isn't just about adding more. Sometimes it's about removing what's holding you back. Luna: Removing the weight. I like that. Let's see who gets it right in the next five years. Lucas: Agreed. Until next time, keep your systems clean and your workflows lean.