# The debt wall > Technical debt is dangerous because it accumulates silently, until the day the company hits a wall. CEOs, take the lead. - Author: Mathieu Eveillard - Published: 2022-07-06 - Updated: 2025-08-03 - Tags: CEO - Canonical: https://www.mathieueveillard.com/blog/dette-technique/ - Translation (fr): https://www.mathieueveillard.com/fr/blog/dette-technique.md ![The debt wall](https://www.mathieueveillard.com/blog/2022-07-06-dette-technique/dette-technique.webp) We have to move fast, prove there’s a market, acquire early adopters, retain them, raise funds, and deliver. So, inevitably, we’re never moving fast enough. So we deployed the PoC to production. Ouch. There’s a lot of client-specific code in there; making it generic would mean really stopping to rethink. And the model that no longer holds up… we don’t have the right business objects, but the refactoring is a Herculean task. It’s all the more frustrating because we’re, how should I put it… a little weak on the testing side. So we put together a QA team to limit the damage: it’s manual regression testing. It’s not sustainable, but we have no choice: we have to deliver. Does this sound familiar? ## Technical Debt: A Matter of Expertise Let’s put it bluntly: **technical debt is first and foremost a matter of the technical teams’ skills**: while writing code that works is within the reach of any developer, writing code that can be evolved to support the company’s growth is a real challenge. The company is constantly adapting to the market and its users, needs emerge as we go along, and the code ends up under strain. The real challenge, when laying the foundation for a product, is to keep it simple without oversimplifying. We shouldn’t anticipate needs that are inherently hypothetical, yet we must allow the code to evolve to meet those needs if they arise, in other words, leave the door open. There is therefore a constant tension between the short and long term, a tightrope you can still walk provided you have the necessary expertise, particularly in terms of [modularity](https://www.mathieueveillard.com/blog/differer-les-decisions) and [testing](https://www.mathieueveillard.com/blog/50-shades-of-tests). These are all things you simply can’t reasonably expect from developers fresh out of school. As a CEO, you’ll always be better off bringing in experienced developers as early as possible to lay a solid technical foundation, a [minimal application skeleton](https://www.mathieueveillard.com/blog/walking-skeleton), which will then allow you to bring on more junior developers to quickly reach the MVP while keeping technical debt to a minimum. ## Technical debt is insidious That said, we’re doing the best we can. Every company grows as best it can; each one has its own history and its own reasons. The people in charge generally try to do a good job and have done plenty of useful things for the company, but the fact is, the debt has piled up. In fact, while we can limit its accumulation, technical debt is, so to speak, inevitable: **writing code is, in itself, creating debt**. That’s life 🥲 The difficulty is that technical debt has two characteristics that make it dangerous: - **Debt begets debt**: if it’s all going to hell anyway, why should I do meticulous work when the codebase is a field of ruins? This is a psychological bias known as the [broken-window theory](https://en.wikipedia.org/wiki/Broken_windows_theory), which must be countered from the very beginning or else the debt will become entrenched. And besides, even with the best intentions in the world, it’s hard to build cleanly on foundations that aren’t sound. - **Technical debt is invisible to non-technical leaders**: from their perspective, the application works, and it’s true! As a result, technical debt can accumulate for years in relative silence, until it suddenly comes to light, perhaps because of a feature that’s a bit too critical or the departure of a key developer. And that’s when you hit a wall. The debt wall is like the wall in a marathon: you put in twice the effort and go half as fast. The instinct to hire new developers to put in more effort turns out to be counterproductive, because it’s the method that’s flawed. You’re just spinning your wheels. Tough break. ## How can we pay it down? So, what do you do when technical debt has become entrenched? Well, you have to act rationally: 1. **Stop creating it**, as much as possible, as soon as possible. That means training your teams and encouraging them to adopt new work standards. It’s a set of best practices (Clean Code, Test-Driven Development, Domain-Driven Design…), which you’d do well to [adopt gradually](https://www.mathieueveillard.com/blog/artisanat-logiciel). Even before the practices themselves, it’s a mindset, that of Software Craftsmanship, characterized by pride in a job well done and a desire to improve as much as to pass on knowledge. This topic therefore touches on your company’s culture. 2. **Pay off existing debt**. This is a long-term effort that requires careful prioritization, [refactoring skills](https://www.mathieueveillard.com/blog/refactoring), and, before that, a very good understanding of the business. In fact, one of the root causes of technical debt is poor modularity across the entire system. It’s therefore very common to have to [re-modularize](https://www.mathieueveillard.com/blog/priorite-modularite) it, which is done primarily based on business considerations. ## Conclusion Technical debt is the biggest challenge for scale-ups, because scaling up brings to light problems that had been lurking in the shadows from the very beginning. A few developers who know the entire history of the codebase can compensate for the flaws in a small codebase that’s poorly modularized, poorly architected, or poorly tested. But what works with two people no longer works with 20 and certainly not with 200. There’s only one rule: take the initiative and challenge your developers! Finally, let’s point out what perhaps should have been said first and foremost: **debt isn’t bad in and of itself**. When faced with a tight deadline, it’s perfectly acceptable to take a few shortcuts in the code if that allows the team to deliver on time. However, this must be a conscious, occasional decision, and the debt must be repaid quickly by performing the necessary refactoring. Remember: “A loan is a commitment and must be repaid. Check your ability to repay before committing.” When used properly, technical debt allows a company to achieve beneficial leverage. The key is knowing how to manage it.