Why most technical debt is a decision, not an accident

We have sat in the meeting where a team decides to skip the unusual case. Not by accident: out loud, in a stand-up or a pull request thread, someone says "we don't have time to handle that properly before the deadline, let's release the simple version and come back to it." Then the deadline passes, the team moves to the next thing, and six months later somebody finds the gap and calls it "technical debt that built up over time." It did not build up. It was chosen, on a specific day, by a specific person, for a specific reason. The problem is not that the choice was made. The problem is that nobody wrote it down.

That distinction matters more than it sounds. Here is the short version of what changes when a team treats technical debt as a decision instead of an accident:

The metaphor was never about sloppiness

The term "technical debt" comes from Ward Cunningham, a software engineer who coined it in the early 1990s while explaining to his manager why a financial application needed rework. His point was narrow and specific: it is fine to release code based on your current best understanding of a problem, the same way it is fine to borrow money, as long as you know you are borrowing and you plan to pay it back. He was not describing rushed or careless work. He was describing a deliberate tradeoff between releasing now with a simpler model and releasing later with a fuller one.

Somewhere between that original idea and how most teams use the phrase today, the deliberateness got lost. "Technical debt" turned into a general label for anything unfinished, confusing, or hard to maintain, whether or not anyone chose it on purpose. That loss of precision is the actual problem. A team cannot manage what it cannot name correctly, and calling every kind of unfinished work "debt" makes it impossible to tell which parts were a real, knowing tradeoff and which parts were just a mistake nobody caught.

Deadline pressure is the real cause, and developers already know it

We do not need to guess at this. In Stripe's 2018 Developer Coefficient survey, which polled more than 1,000 developers and more than 1,000 C-level executives across the US, UK, France, Germany, and Singapore through Harris Poll, 79 percent of developers said that not being given sufficient time to fix poor-quality code has a negative impact on their morale. Another 79 percent said the same about changing priorities that result in discarded code or wasted time. These are not developers complaining about a mystery force called "debt." These are developers describing a decision that was made by people above them, under time pressure, that they had to live with.

The same survey found developers spend an average of 13.5 hours a week addressing technical debt, out of a 41.1-hour work week. That is a large share. That is a third of a work week going toward paying the ongoing cost of choices that were, in most cases, made under a deadline by someone trying to hit a date. The debt did not appear out of nowhere. It was the price of a decision that got made in a hurry and then forgotten.

Naming the tradeoff at the time changes what happens next

Here is the mechanism, stated plainly: a decision that is named when it is made can be evaluated later. A decision that is never named cannot be evaluated at all, because nobody remembers it was a decision.

If a team writes down, at the moment they skip a validation check or release a simplified version of a feature, exactly what they skipped and why, that note becomes something the team can act on. They can revisit it on a schedule. They can weigh whether the deadline that justified it was worth the cost. They can decide, with real information, whether the shortcut is still acceptable six months later or whether it has quietly become the reason a customer found a bug. None of that is possible if the shortcut just disappears into the code with no record.

Compare that to what actually happens most of the time. The shortcut is released. The deadline is met. Everyone moves to the next project. Nobody writes anything down, because writing it down feels like admitting the work is not finished, and nobody wants to say that out loud under deadline pressure. Then, later, someone finds the gap, and it reads exactly like a mistake, because there is no evidence it was ever anything else. The team spends time reconstructing a decision that already happened once, badly, the first time.

The responsibility splits two ways, and both sides have to do their part

A developer who takes a shortcut without saying so is hiding information the team needs. A manager who sets a deadline without asking what got cut is asking for a result without asking what it costs. Both failures look the same from the outside: a gap in the code that nobody can explain later. But they need different fixes.

The developer's job is to report the tradeoff, not to make it disappear. That can be a line in a pull request description, a short comment at the point in the code where the shortcut is, or an entry in a shared list the team already keeps. It does not need to be long. It needs to exist, written by the person who made the decision, at the time they made it, not reconstructed from memory afterward.

The manager's job is to actually hear that tradeoff and decide, knowingly, whether it is worth the deadline. That sounds obvious, but it rarely happens, because most deadlines are set before anyone knows what shortcuts they will require. The fix is not to stop setting deadlines. It is to build in a moment, even a short one, where the team says what will not be done fully, and someone with the authority to accept that risk actually accepts it out loud.

Automated checks turn a named tradeoff into a tracked one

This is where an eval suite, meaning a set of automated checks written from the specification before code is released, proves its value in the process. Two different things happen once that check exists.

First, it catches the debt nobody chose on purpose: the unusual case that was missed because the spec was unclear, not because anyone decided to skip it. That is not a tradeoff. That is a gap in understanding, and a check that runs against the real specification finds it before a customer does.

Second, for the debt that was chosen deliberately, a check tied to the skipped requirement keeps the tradeoff visible instead of letting it fade. If a team knowingly releases without handling a rare input format, a check that fails on that input, clearly labeled as "not yet handled, tracked in [ticket]," keeps the decision visible to the team on every future change. It stops being a fact only one person remembers. It becomes a fact the whole pipeline records.

In the work we do, that is the actual difference between debt that gets managed and debt that gets forgotten. The check does not remove the need for judgment about which tradeoffs are worth making. It makes sure the tradeoff stays a decision the team can revisit, instead of quietly becoming a mystery six months later.

What this means for the next deadline

The next time a deadline forces a shortcut, the fix is not to avoid the shortcut. Sometimes the shortcut is the right decision. The fix is to say so, in writing, at the moment it happens: what got skipped, why, and what it will cost if it is left alone. That single habit is worth more than any backlog review of a large amount of debt nobody can explain.

Thanks to the engineers who have explained their own backlogs to us and were honest about which items on them they actually remembered choosing. Most could not say. That gap, more than the debt itself, is the thing worth fixing.

Debt you name is a plan. Debt you do not name is a problem that will appear later without warning.

Sources

• Stripe, The Developer Coefficient (September 2018): survey of 1,000+ developers and 1,000+ C-level executives via Harris Poll across the US, UK, France, Germany, and Singapore; supports the 79 percent morale-impact figure and the 13.5 hours per week spent addressing technical debt.
• Technical Debt as a Metaphor, on Ward Cunningham's original framing: supports the description of Cunningham's original intent for the term.