Focusing Tech Debt Efforts on ‘Hotspots’ is Key, Argues Luca Rossi

In a recent LinkedIn post, 🌀 Luca Rossi challenges conventional wisdom regarding code quality and technical debt, arguing that efforts should be strategically focused on the most active parts of a codebase rather than on code that is merely poorly written but stable.

🌀 Rossi begins by stating a core tenet of his argument: “Bad code is bad only if you need to change it. If it looks bad, but is stable, it doesn’t pose any concerns.” This perspective suggests that the perceived quality of code should be directly linked to its mutability and the frequency with which it requires modification, rather than its aesthetic or structural perfection.

The Misguided Nature of Traditional Tech Debt Management

According to 🌀 Rossi, much of the work done to address technical debt is often misdirected. He points out that without a clear understanding of code activity, teams may waste valuable resources on stable, albeit unsightly, code segments or, conversely, on areas that are active but already in a reasonable state.

This inefficiency stems from a human tendency to intuitively misjudge code activity. 🌀 Rossi highlights the extreme skew in code activity, noting that in most codebases, a very small percentage of the code—around 5%—accounts for a disproportionately large amount of the development activity—up to 90%.

He elaborates on this point:

“As humans we are bad at judging this intuitively, so a lot of work on tech debt is simply misguided: it either happens on bad—but stable—code, or on areas that are active but already in relatively good shape.”

Lessons from Startup Due Diligence

🌀 Rossi shares a personal anecdote from his startup days involving a technical due diligence process during a potential M&A conversation. The consulting firm identified several areas of poor-quality code, which was not unexpected given the company’s strategic focus.

Over time, the startup had concentrated development efforts on critical product areas, allowing less strategically important or experimental sections to accumulate technical debt, including less rigorous testing and code duplication. 🌀 Rossi explains:

“In fact, over time we had doubled down on specific parts of the product we cared about, while phasing out others. The latter stayed experimental: less testing, more duplication, etc.”

However, the acquiring firm’s assessment did not differentiate between stable, low-activity code and the more dynamic, strategically vital sections. 🌀 Rossi found it challenging to convey this distinction.

The Importance of Frequency of Change

The core issue during the due diligence, as 🌀 Rossi sees it, was the failure to consider the frequency of change. While the startup highlighted its robust, strategically important code, the consultants gave equal weight to the less critical, but poorly written, experimental code. 🌀 Rossi states this observation plainly:

“In other words, the 𝗳𝗿𝗲𝗾𝘂𝗲𝗻𝗰𝘆 𝗼𝗳 𝗰𝗵𝗮𝗻𝗴𝗲 wasn’t considered.”

Although the M&A deal eventually fell through for various reasons, 🌀 Rossi suspects that this disagreement over prioritizing technical debt based on code activity played a role, even if it wasn’t explicitly cited as a deal-breaker. He credits a conversation with Adam Tornhill as a significant influence on his thinking about this topic.

🌀 Rossi’s insights suggest a more pragmatic approach to software development and maintenance, emphasizing the need to identify and prioritize work on the parts of the codebase that are most likely to evolve, thereby maximizing the impact of quality improvement efforts.