We'll Fix It in the Next Sprint (A Eulogy for Every Shortcut That Became a Career)

Every technical debt story starts the same way: with someone in a meeting saying the words "for now."

"We'll hardcode the environment variable for now." "We'll skip the abstraction layer for now." "We'll handle the edge case manually for now." "For now" is the most expensive phrase in software development. It has bankrupted teams, outlasted careers, and survived three rounds of layoffs without ever being addressed.

This is not an article about avoiding technical debt. That article would be very short and mostly fictional. This is an article about what happens after "for now" becomes "forever" — which is more often than anyone wants to admit and more expensive than anyone ever budgets for.

The Compound Interest Nobody Calculated

The original framing of technical debt, coined by Ward Cunningham in the early nineties, was genuinely useful: sometimes you write imperfect code intentionally because the speed-to-market value exceeds the cost of cleanup, as long as you actually clean it up. It's a loan with an understood repayment schedule. Debt as a strategic tool.

What Cunningham did not anticipate — or perhaps anticipated and despaired over — was that most organizations are structurally incapable of repaying that debt once the immediate pressure is gone. The product shipped. The crisis passed. The sprint backlog refilled with new features. The cleanup ticket got deprioritized once, then again, then moved to a separate "tech debt backlog" that no one looks at because looking at it is demoralizing.

Meanwhile, the debt is accruing interest. Every new feature built on top of the shortcut inherits its assumptions. Every new developer who joins the team learns to work around the workaround without understanding why the workaround exists. The original "for now" calcifies into load-bearing architecture that no one is willing to touch because the risk of touching it now exceeds the pain of maintaining it.

The debt hasn't disappeared. It has become infrastructure.

Voices From the Rubble

Talk to developers who have been at the same company for more than four years and you will find a specific type of weary expertise — the expertise of someone who knows exactly where all the bodies are buried because they helped dig some of the graves.

"There's a service we have that was written over a weekend during a product emergency in 2018," one senior engineer at a mid-size fintech company described. "It was supposed to be replaced within the quarter. It now processes about forty percent of our transaction volume. Replacing it has been on the roadmap for three years. Every time we start, we discover something else that depends on it in a way we didn't expect. It's the cockroach of our infrastructure."

Another developer, a staff engineer at a company whose name you would recognize, described inheriting a "temporary" caching layer that had been bolted onto a legacy API to buy time for a proper rewrite. The rewrite never happened. The caching layer grew. It now has its own documentation, its own runbook, and two engineers whose primary responsibility is keeping it alive. "We have people whose entire job is maintaining a workaround," she said. "The workaround is now the system."

This is the cruelest math of technical debt: the cost of maintaining the shortcut eventually exceeds the cost of the original fix, but by the time that's obvious, the shortcut has become so deeply embedded that the fix is now orders of magnitude more expensive than it would have been. You missed the window. The window closed quietly, while everyone was focused on the next sprint.

The Architecture That Ate the Roadmap

There is a particular variety of technical debt that deserves its own category: architectural debt. Not a single bad function or a lazy abstraction, but a fundamental structural decision made under pressure that now shapes everything built on top of it.

Monolithic databases that were supposed to be split into services. Synchronous APIs that were supposed to be refactored to async once the team had time. Authentication systems bolted together from three different approaches because each one was added during a different era of the company's growth. These are not bugs you can fix in a PR. They are geological formations. They require expeditions.

The developers who work inside these formations develop a kind of dark fluency with them. They know which tables you can't query without hitting a timeout. They know which deployments have to happen in a specific order. They know which features can never be built because the data model doesn't support them and changing the data model would require a migration that would take six months and carry a real risk of data loss.

This knowledge lives in people's heads. It is not documented, because documenting it would require acknowledging it, and acknowledging it would require explaining why it hasn't been fixed, and that conversation leads somewhere uncomfortable.

The Honest Accounting

Some teams have started doing what might be called a technical debt audit — a deliberate, honest inventory of known shortcuts, their estimated maintenance cost per quarter, and what it would actually take to address them. The results are usually illuminating in the way that receiving a medical bill is illuminating.

When you add up the hours spent working around a bad abstraction, debugging the symptoms of a structural problem, onboarding new developers to the ecosystem of workarounds, and managing the incidents caused by the accumulated fragility — the number is almost always larger than anyone expected. And it grows every quarter, because every new feature adds more surface area to the debt, more code that assumes the shortcut is stable, more weight on a foundation that was never meant to be permanent.

The argument for addressing technical debt has always struggled against the argument for new features because debt costs are diffuse and ongoing while feature value is visible and immediate. "We could ship the new dashboard this quarter, or we could refactor the service layer" is not a hard choice for most product managers. The dashboard is on the roadmap. The refactor is a risk with no visible upside.

Until it is. Until the system slows to a crawl under load that the architecture was never designed to handle. Until the incident postmortem traces back to a decision made in 2019 with the best of intentions and the most temporary of timelines.

Until someone new joins the team, looks at the codebase, and asks why things are done this way. And the answer, delivered with the tired patience of someone who has given it many times, is: "We'll explain it to you. There's a lot of context."

There is always a lot of context.

The context is the debt.