Digital Debt: When “Just for Now” Becomes Critical Infrastructure

ReadFun Yet InformativeIndustry InsightsVisual InsightStats & Trends
Written by Jeff Winter

Please join me in congratulating our temporary workaround on 12 magnificent years with the company!!!

What began as “something to get us through Friday” has survived three transformation programs and become essential to production. Honestly, I’m impressed. Most employees have to update their skills to achieve that kind of job security. We considered buying it a commemorative watch, but the last time somebody changed a time setting, three systems disagreed about which day it was. So... cake it is. 😀

I find this whole situation funny until I think about the people maintaining it. They made a reasonable decision under pressure, kept things moving, and probably assumed somebody meant it when they said, “We’ll clean this up later.” Twelve years later, those people are still cleaning. Just around the problem. That’s the digital debt cycle: quick fixes add complexity, complexity eats the time needed to improve things, and everyone becomes desperate for another quick fix. Our temporary workaround has accidentally built an empire.

It started with such modest ambitions

Imagine a script moving production records from a manufacturing execution system into an enterprise resource planning system. A few fields, an hourly transfer, nothing dramatic. Then planning needs its output. Quality adds an exception. Finance wants a calculation. Suddenly, this little script contains business rules nobody has documented anywhere else. Its creator asks for vacation. Management requests a continuity plan. (I wish that sounded more ridiculous than it does.) The technical issue is coupling. When applications depend on particular database columns, file layouts, or execution sequences, changing one thing can break several others. Those dependencies become part of the architecture whether anybody formally approved them or not. Apparently, architecture can also happen through collective avoidance.

Over time you inherit data debt, operational debt, and the awkward realization that a critical alert still goes to somebody who left years ago. This is the part that bothers me most: everyone is working hard, yet keeping the thing running keeps making it harder to find time to replace it safely. Even “just run it again” needs thought. If a receiving system records a transaction but its acknowledgment disappears, retrying could create a duplicate. AWS explains why idempotent APIs matter: repeated requests should have the same effect as one. Doubling production in the database is a surprisingly disappointing way to hit your target.

Then there’s the data itself. Equipment identifiers differ. Units need conversion. Timestamps need interpretation. Installing an API gateway or message broker doesn’t magically settle those disagreements, however attractive the architecture diagram becomes. If connectivity drops, teams also need buffering, replay rules, and duplicate detection when service returns. Those behaviors belong in interface specifications and automated tests, including recovery tests.

The empire has excellent growth prospects

MuleSoft’s 2026 Connectivity Benchmark Report surveyed 1,050 IT leaders globally and reports an average of 957 applications per organization, with only 27% connected. Respondents also report IT teams spending 36% of their time designing, building, and testing new custom integrations. I had to pause at 957. 😮 That is a lot of software to persuade into a productive relationship. Integration creates real value, so I wouldn’t label those hours wasted. But each bespoke connection brings behavior someone has to understand, secure, and maintain. Connecting everything indiscriminately could give our distinguished workaround another hundred dependents and an even stronger negotiating position.

What frustrates me is where the bill lands! The next worthwhile project needs dependency checks, data reconciliation, and regression testing before it can move. Meanwhile, the people who could simplify the mess are occupied keeping it alive. We then ask why innovation takes so long, which must be a delightful meeting to attend.

Our workaround would like to welcome AI

Our workaround is delighted! I’m excited about AI’s potential here, but the distinction between creating faster and improving the whole system matters. Atlassian’s October 20, 2026 analysis reports that 87% of developers say AI helps them ship work faster, while 72% experience the same or more workflow friction than before AI. Those are reported experiences; they don’t establish that AI caused every problem. DORA’s March 2026 analysis helps explain the tension: time saved generating code can shift into verification, while fragmented tools and fragile infrastructure undermine the benefits.

Give me AI that helps explain unfamiliar code, uncover dependencies, and draft tests people can validate. I love that possibility. Another undocumented connector with no owner? I’m considerably less enthusiastic. We have just given our digital debt a recruitment department.

Occasionally the celebration interrupts production

“It’s only a setting” makes me nervous. Configuration changes alter system behavior, sometimes spectacularly. Following its November and December 2025 outages, Cloudflare acknowledged that configuration changes could spread globally without the staged safeguards used for software releases. Its May 2026 resilience update described progressive deployment, health monitoring, automated rollback, and removal of unnecessary runtime dependencies. That response offers a useful lesson: contain a bad change, detect it early, and make recovery dependable. “It worked once” should require considerably more evidence before becoming “send it everywhere.”

I would really like to attend the retirement party

The overall approach is simple: decide what needs fixing, then replace it safely. The difficult part is working through the decisions underneath each step:

  1. Assign an owner. Choose someone accountable for the workaround’s future, then clarify who can approve changes, fund the work, and accept the operational risk. Those may be three different people across IT, operations, and finance. If several departments depend on it, who resolves conflicting requirements, and whose budget pays for a benefit everybody shares?

  2. Understand what depends on it. Identify the systems, people, and processes that use its output, including spreadsheets and reports outside the official architecture. Determine which business rules are intentional, which are historical accidents, and which exceptions only appear at month-end or during unusual production conditions. An apparently unused field could still drive an important reconciliation nobody thought to mention.

  3. Decide what to fix first. Compare recurring support effort, production exposure, and opportunities delayed by the workaround. The judgment gets harder when a cheap fix removes a daily irritation while a major replacement addresses a rare but costly failure. Estimate both, make the uncertainty visible, and consider whether replacement risk temporarily exceeds the risk of keeping the current system.

  4. Define what successful replacement means. Agree on the data definitions, business outcomes, and recovery behavior the new solution must deliver. If old and new systems disagree, which result is correct? Decide which legacy behaviors must be preserved and which should change, then test missing messages, duplicates, timing differences, and exceptions. Matching the old output could also mean faithfully reproducing an old mistake.

  5. Replace it in manageable stages. Microsoft’s Strangler Fig pattern describes moving functionality gradually while the existing system operates. Choose boundaries that let you verify each move, decide which system is authoritative during the transition, and establish what can actually be reversed if something fails. Fund time for migration and validation, with clear criteria for switching off each old component.

  6. Cancel the anniversary cake. Once the replacement is proven and every dependency has moved, actually retire the old workaround, including the temporary machinery built to replace it. Otherwise, next year we’ll be celebrating thirteen years of service, congratulating its new assistant, and asking Dave to postpone his vacation because the retirement project has become business-critical.

These steps may sound simple. But integrating them into the culture and processes of a business is quite difficult, especially when deadlines reward the quickest fix and nobody is measured on the complexity left behind. Ownership, documentation, testing, and time for improvement have to become part of how work gets planned, funded, and delivered. Fixing a set of workarounds today is relatively easy compared with preventing them in the first place. That means addressing the disconnected systems, conflicting incentives, and broken handoffs that keep making another quick fix necessary. The harder work is changing those conditions so we stop rebuilding the same problems.

References:

Jeff Winter
Next

AI Can Do Almost Anything. Your Company Shouldn’t.