Technical debt
A shortcut can be reasonable if managed. Understand technical debt, its costs, and the right questions to ask before deciding to rebuild your entire website.
Sur cette page4 sections
There is the drawer we tidy properly, and the one where we shove everything, telling ourselves we'll deal with it on Saturday. As long as you aren't looking for anything, the second one seems to work just as well. The day you need to find a specific invoice, you understand what you had put off until later.
Technical debt reminds me of that. A website can work perfectly for visitors while becoming increasingly painful to modify for the person looking after it. The problem isn't always visible on the homepage. It appears when you want to change something that seemed simple.
The shortcut can therefore be reasonable. The real issue is what happens when you want to add a second package: did we plan for the area that needs updating, or do we have to figure out how everything is held together?
La technical debt metaphor describes this gap between the time saved now and the extra work it might add later. And not all debt is taken on consciously: Martin Fowler's quadrant also distinguishes what we discover through experience. We might have made a choice in good faith, then later realise that a different structure would have supported the project better.
At first, copying the price was quick. Later, each modification costs a bit more time and attention. This is where the debt image becomes clear: you pay for the shortcut multiple times, not just on the day you took it.
The same phenomenon exists with a setup known by only one person, or with a part of the site you no longer dare touch because you don't know what it might break. It isn't necessarily visible to visitors, but it eventually weighs down the updates you can request.
For the copied price, one answer could be to centralise it and then check the places where it is displayed. For a fragile deployment, we can start by describing the procedure and making it reproducible. These are two very different interventions; they don't automatically justify a complete overhaul.
Conversely, if every major update forces you to bypass the same limits, a rebuild can become logical. We then compare the rework to the corrections we would continue to accumulate. The choice is based on the project, not on the desire for new code.
We can note what we postpone and address it when it starts to hinder an update or create a risk. La maintenance can accommodate this work, with specific actions rather than a permanent major project to make the code perfect.
If you are looking for signs to spot on your site, I talk about it more concretely in this article on diagnosing technical debt. Here, what I would especially like to leave you with is the right to make a trade-off without telling yourself it is free. We can close the drawer today. It simply helps to know what we put in it and when we plan to reopen it.
Technical debt reminds me of that. A website can work perfectly for visitors while becoming increasingly painful to modify for the person looking after it. The problem isn't always visible on the homepage. It appears when you want to change something that seemed simple.
Sometimes there are good reasons to close the drawer
Imagine you are launching a business with a single offer. We could immediately develop a system capable of managing twenty packages, or start with the one you actually need. Spending time on the other nineteen before knowing if the business works isn't necessarily the best choice.The shortcut can therefore be reasonable. The real issue is what happens when you want to add a second package: did we plan for the area that needs updating, or do we have to figure out how everything is held together?
La technical debt metaphor describes this gap between the time saved now and the extra work it might add later. And not all debt is taken on consciously: Martin Fowler's quadrant also distinguishes what we discover through experience. We might have made a choice in good faith, then later realise that a different structure would have supported the project better.
A small change that requires opening five files
Take a price copied onto the services page, in a form, in the confirmation email, and in a downloaded document. To change it, you have to remember all these places. If you forget one, two clients might receive different information.At first, copying the price was quick. Later, each modification costs a bit more time and attention. This is where the debt image becomes clear: you pay for the shortcut multiple times, not just on the day you took it.
The same phenomenon exists with a setup known by only one person, or with a part of the site you no longer dare touch because you don't know what it might break. It isn't necessarily visible to visitors, but it eventually weighs down the updates you can request.
You don't empty the whole house to tidy one drawer
When you discover this, the temptation is sometimes to redo everything. I understand: starting fresh gives the impression that you'll finally be able to breathe. But you have to move content, accounts, data, and user habits. It's no longer just about code.For the copied price, one answer could be to centralise it and then check the places where it is displayed. For a fragile deployment, we can start by describing the procedure and making it reproducible. These are two very different interventions; they don't automatically justify a complete overhaul.
Conversely, if every major update forces you to bypass the same limits, a rebuild can become logical. We then compare the rework to the corrections we would continue to accumulate. The choice is based on the project, not on the desire for new code.
"Later" deserves a place in the calendar
The shortcut that worries me most isn't necessarily the one taken for a first version. It's the one forgotten afterwards, while the site continues to grow around it.We can note what we postpone and address it when it starts to hinder an update or create a risk. La maintenance can accommodate this work, with specific actions rather than a permanent major project to make the code perfect.
If you are looking for signs to spot on your site, I talk about it more concretely in this article on diagnosing technical debt. Here, what I would especially like to leave you with is the right to make a trade-off without telling yourself it is free. We can close the drawer today. It simply helps to know what we put in it and when we plan to reopen it.
