Article Craft #1: The technical debt

Why this article?

"We have too much technical debt." That's the diagnosis we hear from 90% of the CIOs and CTOs we meet. They see it as the root cause of all their problems: slowness, bugs, inability to innovate.

Yet, through our work as reinforcement teams, we've consistently observed the same thing: the real bottleneck is rarely in the code. Behind "insurmountable debt" there are often organizational problems: a culture of urgency that makes it impossible to say "no," business decisions made without understanding their technical impact, or teams that have lost sight of their mission. This article aims to bridge the gap between business and technology: debt is not a bug — it's a management tool.

Abstract

Technical debt is often the scapegoat for stagnation. But wanting to eradicate it is an illusion. The real danger is not its existence, but the lack of governance around it. When it becomes invisible or unmanaged, it doesn't just paralyze the system — it paralyzes decision-making. This article explores how to move from "fatal" debt to a consciously managed strategic lever.

Introduction

Technical debt has become the universal excuse: "We can't ship — it's because of the debt." This explanation is comfortable because it lets everyone off the hook. It is also largely false.

Technical debt is not an inevitable material reality like the wear and tear of a machine. It reflects our choices. The real problem is not the debt itself, but the irresponsibility in how it is taken on, ignored, and passed on.

1. Technical debt is an economic tool, not a moral failing

The debt metaphor, introduced by Ward Cunningham, describes a deliberate trade-off: ship faster today, at the cost of additional effort tomorrow. As Arnaud Lemaire points out, technical debt is inseparable from delivery flow.

The analogy: Launching software with zero debt would be like refusing to take out any loan to start a business — theoretically possible, practically paralyzing.

Debt only becomes a problem when it is no longer visible, intentional, or repayable.

2. The real divide: conscious debt vs. unconscious debt

The dividing line is not between good and bad debt, but between what is managed and what is merely endured.

• Conscious debt: An explicit trade-off, with estimated future cost and an identified repayment threshold.
• Unconscious debt: No one knows why the code is the way it is, the original authors have left, and the business has no idea of the risks. Every change becomes a battle.

Many of us believe it is not the debt itself that kills systems, but the absence of a governance mechanism to make it visible and open to arbitration.

3. An organizational problem before a technical one

In many organizations, debt is invisible to the business side and internalized as a source of suffering by the technical teams.

The real bottleneck: We have seen companies convinced their code was "dead," when the actual blockage came from a decision-making process so slow that no one dared propose any change. The problem was not the software's complexity — it was a culture of fear.

It is fear that leads some software vendors to miss major technological shifts and act far too late, often only after an organizational shake-up. Fear also holds back organizations that want to wipe out their debt in one go. An iterative, incremental approach to modernization is often both possible and preferable — it forces a focus on what truly matters.

A debt that cannot be renegotiated with the business is no longer a debt — it is a toxic liability.

4. The key role of Craft: making trade-offs explicit

Software Craftsmanship does not eliminate debt — it imposes a discipline: making it visible. A responsible developer doesn't say: "We don't have time to do it properly." They say: "Here is what we are simplifying today, and here is what it will cost to stabilize it later."

5. Not all debts are created equal

Martin Fowler's quadrant remains the reference framework:

1. Prudent & Deliberate: Healthy, strategic.
2. Prudent & Inadvertent: Inevitable learning.
3. Reckless & Deliberate: Often politically driven and risky.
4. Reckless & Inadvertent: Pure negligence.

This last yellow quadrant is not "debt" — it is a skills deficit.

6. A mature team doesn't eliminate debt — it governs it

High-performing teams integrate quality as a product decision variable. They measure the real cost (delays, bugs, friction) and make ongoing trade-offs. Mastering your debt is not just about refactoring — it's about governing your technological assets.

Conclusion

Technical debt is not a failure. Ignoring it, hiding it, or passing it on without explanation is. A software system is a living asset. Professionalism means choosing how and why it degrades.

The next time someone says: "We have too much technical debt," the only useful question is: "Which kind? Why? And what are we concretely going to do about it?" If no one can answer, the problem is not technical. It's irresponsibility.