Managing Technical Debt: Interest Rates, Impact, and Continuous Payments

5 min read

In my earlier article, Advocating for Refactoring Prioritization in the Context of Business Goals, I discussed the importance of aligning refactoring efforts with business objectives. As I continue working with cross-functional software delivery teams, a persistent challenge remains: How do we prioritize technical debt alongside feature work?

One of the challenges many of us experience across software delivery teams is balancing technical debt work with feature development, defect resolution, and risk mitigation. Too often, technical debt becomes a “later problem”—a looming burden that teams only address during rare, large-scale cleanups. This reactive approach is costly, time-consuming, and disruptive. What if teams treated refactoring like paying down a car loan or mortgage instead? By making continuous, small payments, teams can manage their technical debt effectively, avoid major disruptions, and maintain a healthier codebase.

This topic resurfaced for me while listening to Martin Fowler’s recent conversation on a podcast on technical debt¹. Fowler discussed how the metaphor of technical debt as financial debt helps teams decide when to “pay interest” (live with the consequences of cruft) versus when to “pay down the principal” (refactor and improve maintainability). He emphasized that the real power of this metaphor lies in evaluating the cost of inaction—understanding how much harder it becomes to work within a debt-ridden system and deciding when the trade-off is no longer sustainable.

One idea that resonated with me is the importance of treating technical debt like financial debt in a more structured way. Not all debt is equal—some accrue high interest (actively slowing down teams and introducing defects), while other debts have low interest (minor inefficiencies that don’t immediately impact delivery).

As a software engineer and leader, I strongly support a simple approach many in the industry advocate: regularly addressing small amounts of technical debt instead of letting it build up into a bigger problem. As Martin Fowler warns about letting cruft pile up, teams must proactively incorporate refactoring into their daily work. Instead of waiting for large-scale cleanup efforts, we should treat refactoring like making the minimum payments on a loan—ensuring that technical debt never compounds to an unmanageable state.

Technical Debt as a Loan: The Power of Minimum Payments

To extend the metaphor of technical debt as financial debt, let’s consider how we approach paying off a loan:

Minimum payments: Even if you can’t pay off your entire loan right now, making regular minimum payments ensures the debt doesn’t spiral out of control.
Lump sum payments: Occasionally, you might have the opportunity to pay down a large chunk of principal, significantly reducing future interest.

When applied to software development, these concepts offer a useful lens for managing technical debt:

Minimum payments: Every time a team touches a section of code, they should commit to improving it incrementally—whether through refactoring, improving test coverage, or simplifying logic. Minimum payments is akin to pulling small weeds in a garden whenever you see them, preventing them from growing into a tangled mess.
Lump sum payments: Occasionally, teams may need to dedicate focused effort to resolving high-interest debt, such as a major architectural refactor or addressing systemic issues in a critical module.

By regularly making small improvements, teams can prevent technical debt from accumulating to the point where it requires costly interventions.

Integrating Minimum Payments into Daily Work

Refactoring should not be a separate project or deferred until a “later” that rarely arrives. Instead, it should be a continuous part of the development process woven into every task. Here’s how teams can make this mindset part of their daily work:

Adopt the “Boy Scout Rule”: Leave the codebase better than you found it. Each time a team touches a file, they should look for opportunities to simplify or improve it, even if it’s just removing a small piece of cruft or adding a meaningful test.
Refactor within feature work: When building a new feature, allocate time to clean up the surrounding code. For example, if adding functionality to a poorly written class, take the opportunity to refactor it into a more maintainable structure.
Set aside capacity for improvement: As teams plan for feature work, defects, and risks, they should explicitly allocate capacity for technical debt. Allocating capacity doesn’t always mean large refactoring efforts—it could simply mean committing to small, meaningful improvements during sprint planning.
Make refactoring visible: Use tools like Jira or technical debt registries to track and prioritize technical debt. By making this work visible, teams can demonstrate its value and ensure it’s considered during planning.

These practices ensure that teams always make minimum payments on their technical debt, reducing the risk of accumulation.

Balancing Technical Debt and Business Outcomes

While continuous payments are vital, teams must prioritize technical debt work based on its impact. Just as interest rates guide financial decisions, teams can evaluate technical debt’s “interest rate” to decide when and where to focus their efforts.

Here’s how teams can assess technical debt:

Interest rate: What is the cost of maintaining this debt? Does it slow development, increase defect rates, or create deployment risks?
Impact of repayment: What business or customer outcomes will this debt improve? For example, will it accelerate feature delivery or enhance customer reliability?
Visibility: How often does this debt surface? If it’s in a rarely used module, it may be a lower priority than debt in a core system.

For example:

A low-interest debt might involve minor inefficiencies in logging frameworks, which can be deprioritized in favor of high-impact features.
A high-interest debt, such as a tightly coupled architecture that slows feature delivery, should take priority because it can significantly impact productivity and customer outcomes.

These criteria allow teams to decide how much effort to allocate to technical debt versus other priorities.

Teaching Advocacy for Technical Debt

One of the challenges I’ve seen is that technical leads and managers often struggle to advocate for technical debt. Product owners naturally excel at framing features in terms of business outcomes, such as increased revenue or customer satisfaction. Technical leads must develop a similar skill: speaking the business language to articulate the value of addressing technical debt.

Here are some strategies for building that advocacy:

Focus on outcomes, not processes: Instead of saying, “We need to refactor this code,” say, “Refactoring will reduce our lead time by 20%, enabling us to deliver features faster.”
Leverage metrics: Quantify the impact of technical debt using cycle time, defect rates, or other engineering metrics.
Collaborate with product owners: Work with product owners to align resolving technical debt with roadmap goals. For example, focus on fixing critical debt before major feature launches to allow enough time for resolution and keep the efforts on track.

Technical debt management is not about waiting for a perfect moment to act. It’s about weaving continuous improvement into the fabric of daily work, balancing short-term business goals with long-term sustainability. With the right mindset and advocacy, we can ensure that technical excellence and business outcomes go hand in hand.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: [email protected]