Bad Code Is a High-Interest Loan: How Technical Debt Slowly Kills Team Velocity

Thank you @paolozero , I really appreciate your comment, especially the distinction between intentional and silent debt. That’s a nuance I didn’t fully unpack, and you’re right: not all debt is created equal.

I like how you framed “leverage vs. liability.” I’ve seen that play out too: teams making conscious tradeoffs to learn fast, then actually circling back to clean things up. When that loop exists, debt can be a tool. When it doesn’t… it becomes exactly the kind of drag I was warning about.

Your point about engineers avoiding parts of the system hits hard. That’s usually the moment when debt stops being an abstract concept and becomes a cultural problem. Once people start routing around the code instead of improving it, velocity loss is just the visible symptom.

If I were to extend my own argument after your comment, I’d say: the real danger isn’t just the “interest rate”, it’s losing the team’s willingness to engage with the codebase at all.

Thanks for adding that layer, this is exactly the kind of discussion I was hoping the article would spark.

Thanks @lucaferri, you captured exactly what I was trying to get at with the “invisible tax” idea.

That’s been my experience too. The danger isn’t the big failure, it’s the normalization of friction. When everything feels just a bit slower, a bit harder, a bit riskier, teams stop questioning it. It becomes “just how things are.”

I especially like your framing of making the interest visible as a percentage cost. That shift from “messy code” to “ongoing business expense” is powerful, because it moves the conversation out of opinion and into tradeoffs.

To your question, yes, but I’ll be honest, it’s never perfectly precise, and trying to over quantify it can backfire. What I’ve found works is a mix of lightweight signals rather than a single “number”:

• Cycle time deltas, how long similar changes take in clean vs messy areas
• Change amplification, “this small feature required touching 6 files instead of 2”
• Defect correlation, hotspots where regressions cluster after changes
• PR friction, longer review times, more back and forth on certain parts of the codebase

Individually, each of these is a bit fuzzy. Together, they tell a story that’s hard to ignore.

Sometimes I’ll even frame it narratively rather than numerically:
“This feature took 3 days. In a healthier part of the system, it likely would’ve taken 1.”

It’s not scientifically exact, but it’s concrete enough for stakeholders to grasp the cost.

The key, I think, is consistency, not proving the exact interest rate, but repeatedly showing that the same areas incur the same kind of drag. Over time, that pattern builds trust and makes the repay vs defer conversation much easier.

And you’re absolutely right, most teams don’t decide to carry high interest debt, they just underestimate how quickly “later” arrives.

Thank you @elenchen for your comment!
I love the “architectural friction” framing, that clicks immediately.

When I talk to non-technical stakeholders, I avoid the word “debt” entirely and reframe it in terms they already care about: risk, speed, and cost.

Instead of saying “we need a refactor sprint”, I’ll say something like:

• “This area is slowing feature delivery by X%”
• “A failure here would block critical flows”
• “Scaling this as-is will increase infra cost or incident risk” The key is to make the “interest” visible in business terms.

I also try to tie repayment directly to the roadmap, not against it. For example:

• “If we spend 1 week here, the next 3 features will ship faster and safer”
• “If we don’t fix this now, this upcoming feature will take 2x longer” So it becomes an enabler of delivery, not a detour from it.

What usually works best is pairing it with a concrete moment, like before a scaling event or a risky launch, exactly like you mentioned. That’s when the cost of not acting is easiest to understand.

Thanks for sharing this, @apex_stack , this is a fantastic extension of the idea, and the example makes it very concrete.

I really like how you push the “high-interest loan” analogy further into programmatic systems. At that scale, the impact of technical debt stops being linear and becomes multiplicative. It’s not just that a change is harder, it’s that every small flaw is instantly replicated across thousands of pages, as you described.

Your point about the type of impact changing is especially insightful. In a typical codebase, we tend to feel the cost as slower development. But in your case, the feedback loop is external and much harsher: search engines effectively act as an unforgiving validator of quality. When template debt accumulates, the penalty isn’t just velocity, it’s visibility and reach.

The fact that the only viable option was to delete the entire page type is telling. That’s the “default moment” of the loan, where incremental repayment is no longer enough and you’re forced into a full reset. It’s a powerful illustration of how ignoring compounding debt can eventually remove optionality altogether.

I also really like your takeaway: in template-driven systems, the interest rate scales with distribution. That’s a great mental model: it suggests we should treat templates and generators as high-leverage assets; the kind where quality standards need to be higher, not lower, precisely because of their amplification effect.

This adds an important dimension to the original argument: technical debt isn’t just about time, it’s about surface area and the larger the surface area you’re projecting onto (like 100K+ generated pages), the less forgiving the system becomes.

Really appreciate you bringing in this perspective, it makes the risks of “small” shortcuts much more tangible.

Thanks so much for this thoughtful comment, @christiecosky . You’ve captured something really important that often gets overlooked.

I completely agree: it’s not the “messiness” of code that drives people away, it’s the uncertainty. When the cognitive cost of rebuilding a mental model gets too high, even experienced developers start optimizing for safety over improvement. At that point, “leave the code better than you found it” quietly turns into “don’t break anything and get out.”

What you’re describing is exactly the moment when technical debt compounds. The system stops being a shared asset and starts becoming territory. And as you said, once knowledge stops distributing, you don’t just have a maintainability issue, you get a coordination bottleneck and a real bus factor risk.

I also really like your framing of readability as a performance constraint. That resonates a lot, especially now. With the rise of AI assisted code generation, we’re producing more code than ever, but not necessarily more understandable code. If anything, the gap between code that works and code that can be safely evolved by a team is getting wider.

To me, this reinforces a subtle shift in how we should think about quality: readability isn’t just a nice to have or a matter of taste, it’s what enables continuous change. Without it, velocity might look fine in the short term, but it’s quietly borrowing against the future, which ties back nicely to the high interest loan analogy.

Really appreciate you adding this perspective. It sharpens the argument in a meaningful way.

Thank you @mickyarun ! That’s such a perfect real-world example, especially in fintech where the “interest” is literally measurable.

The cascading retries point is exactly it. The system looks fine at low scale, then suddenly the hidden cost surfaces all at once and hits both infra and reliability.

I really like your reframing. “Reducing the cost of the next feature” is the right mental model because it connects directly to delivery, not just code quality.

I’ve seen the same shift work well. As soon as the conversation becomes:

• faster future features
• fewer incidents
• lower operational cost

it stops being a tradeoff and starts being an investment.

And you’re right, the hardest part isn’t spotting the debt, it’s choosing to act before it becomes painful. Most teams wait for the spike you described, but the ones that scale smoothly are the ones that treat those early signals seriously.