You’re already paying for it

Aging software rarely fails in a day. It gets harder to change and more expensive to run, a little at a time, and none of it shows up as a single line item. The cost of legacy software builds quietly, until something forces the bill.

Engineers call it technical debt. It’s worth understanding even if you never write a line of code, because you’re the one paying the interest.

Two kinds of debt

Some debt is deliberate. Someone chose a shortcut to hit a deadline, knowing it would need cleaning up later. That can be a reasonable trade. The trouble is that later rarely comes, because there’s always another deadline.

Most debt in an aging system is the other kind, the kind nobody chose. Frameworks fall out of support. Vendors retire products. Workarounds pile up around problems that were never fixed. And the people who understood why the system was built the way it was move on, taking that understanding with them. Nobody keeps a list of it, so it grows unnoticed.

It shows up as friction

Changes take longer than they used to. Estimates keep growing. A monthly report needs a manual step that nobody remembers adding. Only one person is allowed to touch the billing module. Each of these looks small on its own. Together, they’re interest payments, and the system still works, so nobody calls it a problem.

When it comes due

In December 2022, a winter storm disrupted air travel across the country. Most airlines recovered within days. Southwest didn’t. Its crew-scheduling system was overwhelmed and couldn’t keep track of where pilots and flight attendants were, and the airline ended up canceling nearly 17,000 flights and stranding more than two million passengers. Refunds and penalties ran past $700 million, including the largest fine the Department of Transportation had ever issued for consumer protection violations.

The storm was only the trigger. The problem had been building for years, in systems that handled ordinary days well enough.

It usually doesn’t take a storm

For most companies, the trigger is quieter. One of our clients ran its core operations on a system built in-house over many years. During the pandemic, its developers left, including the one manager who understood the system best. A capable leader from another part of the business inherited it. The system still ran, but keeping it running was costing more every year, and the question shifted from how to maintain it to whether it could carry the business for the next decade. We took over that system, and later rebuilt it. Read how it unfolded.

Finding it first

Every system carries some debt, and getting rid of all of it isn’t realistic. What matters is knowing what you’re carrying: what the system actually does, what it depends on, and what only one person understands. Very little of that is visible from the outside, which is what an Assessment is for.

Once you can see it, you can decide what to pay down first and what can wait. For a way to think through that decision, see Modernize, Stabilize, or Leave It Alone.

Either way, it’s there. Finding it on an ordinary Tuesday costs a lot less than finding it during your busiest week of the year.