When code becomes a time bomb

$1.52 trillion.

This is the estimated cost of technical debt in the United States in 2022 (one-third of the world's code), according to the Consortium for Information & Software Quality. That’s 7% of the country's GDP.

A staggering sum that goes beyond poorly written code. It includes entire systems that have become rigid, vulnerable to cybercrimes, poorly designed architectures, and features that users have ignored for years due to a lack of meaningful updates.

Take a billing software that no longer complies with regulations. Instead of adapting it, users have developed workarounds to cope with its flaws. When modernizing it, there’s a high risk of reproducing the same misunderstandings, automating wrong choices instead of solving the real problem.

Lean teaches us that technical debt is not fought solely with code but with a sociotechnical model. First, a radical quality approach: identifying concrete problems, studying support tickets, improving communication with clients, and fostering self-quality cherished by software artisans. Then, an architectural approach that aligns all developers.

A software system is a living organism. The larger it grows, the harder it becomes to understand. Contrary to popular belief, code alone is never sufficient to be readable and explicit. Nothing beats a good team-drawn diagram to visualize the architecture and avoid misalignment. Misalignment generates technical debt: between developers and what they produce, and between a team and the system's global vision.

Large companies have often worsened this misalignment by entrusting architecture to isolated experts, dictating choices without dialogue with field teams. This is a legacy of Waterfall and the SAFe framework, which pushed some agile approaches to avoid formal architecture altogether. But abandoning architectural facilitation means losing control over long-term quality.

Finally, there’s software maintenance. Code that works today won’t work forever. In the industry, Total Productive Maintenance (TPM) has radically improved quality by relying on three simple principles, detailed in an excellent article by Michael Ballé: developing team autonomy in maintenance, treating each piece of equipment as unique, and dedicating a maintenance function that intervenes quickly and handles complex cases. These principles align closely with the maintenance system described by Google in their book Software Engineering at Google.

Lean methods have enabled the automotive industry to move from an era where new cars had to be returned to the dealership to a standard where vehicles start and run smoothly.

In software, we’re not there yet. But it’s time to apply to software what revolutionized the industry—non-negotiable quality. Building sustainable systems means giving engineers the means to maintain their code daily and care for every part of the system as if it were a living organism. The question isn’t whether software will age poorly, but whether we’ve put the right conditions in place for it to evolve without blowing up.

This editorial was published in the March 2025 issue of the Taktique newsletter.