Technical debt
A shortcut can be reasonable if managed. Understand technical debt, its costs, and the key 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 realise what you had put off until later.
Technical debt reminds me of that. A website can work perfectly well 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 to be updated, or do we have to figure out how everything holds together?
La metaphor of technical debt describes this gap between the time saved now and the work it may add later. And not all debt is taken on consciously: Martin Fowler's quadrant also distinguishes what we discover through experience. You might have made a choice in good faith, only to later realise that a different organisation would have better supported the project.
At first, copying the price was quick. Later, every modification costs a bit more time and attention. This is where the debt analogy makes sense: you pay for the shortcut multiple times, not just on the day you took it.
The same phenomenon exists with a setup known only to 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 solution could be to centralise it and then check the places where it's displayed. For a fragile deployment, you could start by documenting 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 may become logical. You then compare the rework to the cost of the fixes you would continue to accumulate. The choice is based on the project, not on the desire for shiny new code.
You can note what is being postponed and address it when it starts to hinder an update or create a risk. 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 discuss this 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's free. You can close the drawer today. It simply helps to know what you put in it and when you plan to open it again.
Technical debt reminds me of that. A website can work perfectly well 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. You 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 to be updated, or do we have to figure out how everything holds together?
La metaphor of technical debt describes this gap between the time saved now and the work it may add later. And not all debt is taken on consciously: Martin Fowler's quadrant also distinguishes what we discover through experience. You might have made a choice in good faith, only to later realise that a different organisation would have better supported the project.
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, every modification costs a bit more time and attention. This is where the debt analogy makes sense: you pay for the shortcut multiple times, not just on the day you took it.
The same phenomenon exists with a setup known only to 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 a 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 solution could be to centralise it and then check the places where it's displayed. For a fragile deployment, you could start by documenting 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 may become logical. You then compare the rework to the cost of the fixes you would continue to accumulate. The choice is based on the project, not on the desire for shiny new code.
'Later' deserves a place in the calendar
The shortcut that worries me most isn't necessarily the one taken to release a first version. It's the one forgotten afterwards, while the site continues to grow around it.You can note what is being postponed and address it when it starts to hinder an update or create a risk. 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 discuss this 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's free. You can close the drawer today. It simply helps to know what you put in it and when you plan to open it again.
