What Is Technical Debt? Why We Allow it to Accumulate and How to Identify Warning Signs (Part II)

—

By Aaron Sylvan, 10x Senior Technologist

In Part One of this series, I gave a simple example of technical debt. In Part Two below, we’ll explain why it might actually make sense to accumulate technical debt at first, and how to identify potential warning signs in your company or organization.

Why Developers Accumulate Debt
Investors use debt as leverage. Too much can lead to drowning, but the convenience of a morning coffee with a credit card, or plane tickets that earn reward points, or the equity in an appreciating home — can all be fiscally prudent.

In the case of programming, there’s nothing wrong with doing something the “quick and dirty way” at first. It’s like scribbling a poem in pencil with cross-outs, before writing the final version in calligraphy. You should start off with a draft that will need replacement.

When a project begins, sometimes the programmer needs to flesh out the parts before knowing how it will be in the end. It’s not wrong to sketch a version of code with insufficient comments and missing test cases. Or “bad practices” like “magic numbers”. Many coders begin with copy-paste from public code libraries like StackOverflow or <gasp> an AI code-assist tool.

It is right to work fast in the beginning, and that means debt.

The challenge is that you need to pay your entire credit card balance each month, so it doesn’t start accruing interest. It’s not okay for a developer to abandon their code after the first time it runs successfully. All the proper practices (which most devs know), need to be followed before moving on to the next project.

Signs Your Team Is Drowning in Debt

Sustaining vs. New Development

One way I gauge whether a team is overwhelmed by debt is to track the ratio of bug-fix work to new-feature work. If more than 20% of developer hours go into patching bugs or supporting old code, it’s likely there’s an underlying architectural problem. Healthy organizations typically keep fixes below that threshold so developers can spend most of their efforts creating new value.

Ripple Effects of Poor Code

Another warning sign appears when adding even a small feature triggers a cascade of issues in parts of the product you didn’t touch. That indicates the overall system design—its “foundation”—might be fragile or overly complex. If engineering time is frequently spent addressing knock-on bugs, it’s probably time for a deeper refactor.

Navigating Major Overhauls and Growth

When Debt Becomes a Crisis

At some point, organizations reach a tipping point. Sales teams can’t deliver on customer promises, developers feel overworked, and all efforts are directed at firefighting.

Dealing with Resistance

Not everyone greets an overhaul with enthusiasm. Some developers dig their heels in, worried that reworking old code will reflect poorly on them. Others become territorial over specific sections of the system. My approach is to emphasize a shared goal: building a robust, maintainable product that benefits everyone.

Conclusion

Technical debt isn’t inherently a failing—it’s the tradeoff companies make to deliver quickly. Yet if that debt accumulates unchecked, new features slow to a crawl, and teams start fracturing. By monitoring bug-fix overhead, adopting disciplined coding practices, and committing to well-timed refactors, organizations can stay nimble. In the next part of this series, I’ll explain how to tackle technical debt and why having an outside perspective can do wonders for various organizations.

What Is Technical Debt? Why We Allow it to Accumulate and How to Identify Warning Signs (Part II)

Hiring technical talent doesn't have to be painful.

Frequently Asked Questions: