Technical debt: why shipping features isn't always the right call
In many .NET projects, continuing to ship new features isn't always the right decision.
When you join a project with some experience behind you, you spot very quickly, technically, what's going to hurt. The real question becomes: how do you make those problems visible to decision-makers whose view of the project is limited to the roadmap and the features?
The first signals: what got postponed
When you land on a .NET project, the first signals are often the same. First, there's what got pushed back over time:
- an outdated .NET version, out of support;
- obsolete or unmaintained dependencies;
- known migrations, forever postponed.
Those are choices. Debatable ones, but understandable in a prioritization context.
Then there's the quality of the foundation
- poorly organized code, hard to maintain, duplication;
- shaky architecture;
- no unit tests;
- few or no logs, no clear picture of what happens in production;
- unhandled errors that can crash the app.
Here, we're not talking about optimization anymore, we're talking about fragility. Technically, these aren't incidents yet, as long as production holds. But developers know these weak signals.
And the human signals everyone forgets
- no documentation, or docs that are 3 years old;
- a developer leaves = their knowledge leaves with them;
- devs who only know "their" part of the project;
- the "we'll get to it later" dating from 2021;
- tests commented out "temporarily";
- the file nobody wants to touch.
All of this hurts the project, the deadlines, the quality and the motivation. And everyone stays in their corner, as if everything were fine.
Every feature raises the risk
In that state, every new feature increases production risk. One day invested today to stabilize and secure the codebase saves several days later on emergency hotfixes and refactoring, a message I've often had to deliver on assignments.
Staying silent is also a choice. Even if speaking up means challenging the roadmap with your manager, or their manager. And it's not developer fussiness: it's about reliability and the ability to act quickly and calmly in production.
Making it visible to the business
On the projects I've worked on, I noticed these topics only truly land once you stop framing them as "technical problems".
Takeaway: the moment the conversation is about reliability, company image, user impact and person-days lost, the message is better understood, and above all, better heard.
This article comes from one of my LinkedIn posts (in French), join the discussion ↗