Maintainability debt gets expensive when work runs through it. Match code churn against the roadmap to decide what to refactor and what to leave alone.
The premise (that code that doesn’t see active development doesn’t accrue tech debt) is wrong.
We have one of those “ugly but stable” modules at work. It was largely untouched for the better part of a decade. So, great, it worked for 7 or 8 years without much change, so no cost outside the initial development no?
Well now it’s the time to update the code to work with a new version of a framework. Only the new target version of the framework is two major versions ahead of the one that was supported by the last patch, circa 5 years ago, and 4 major versions ahead of what the original version was developed to support. This support is also not provided by us, but by a dependency that was already deprecated when the original code was written. This dependency was vendored and modified to make the whole thing work.
Version 2 of this dependency was born, developed, deprecated, and abandoned in this time span. When it was abandoned, the migration path was to switch to a different dependency in the same problem space.
The original author of the module (and vendored dependency changes) is gone, and nobody knows how the module works. It’s also written incredibly messily.
So at this point the only solution is to rewrite the whole module.
The question then is: will a complete rewrite, by people that have no context of the original problem space or familiarity with the technology, cost more or less than it would have cost to gradually reduce the tech debt over the course of the last 8 years, by the original authors?
The only code that doesn’t accrue tech debt is not the one that doesn’t change, but that that will never change.
Now since whether a piece of code will never need to change is unknowable, it is unknowable whether unchanging code is accruing debt.
So as it often happens, if you don’t schedule maintenance for your code, your code will schedule maintenance on your behalf. And since by definition time for unscheduled maintenance is not scheduled, those issues will always fall at a bad moment.
I don’t know chief, I’m not convinced. Maintain your code.
My takeaway from the article was, in the author’s own words, “start with debt in code you’re about to change anyway”. That’s not to say you shouldn’t tackle technical debt in code that isn’t changing, rather it’s lower priority.
Yup, the longer you wait to update something, the higher the cost to eventually do that. I hate the “if ain’t broke don’t fix it” adage because of this. If I am the one who will eventually need to update it, you bet I will be “fixing” it more often than I have to.
The premise (that code that doesn’t see active development doesn’t accrue tech debt) is wrong.
We have one of those “ugly but stable” modules at work. It was largely untouched for the better part of a decade. So, great, it worked for 7 or 8 years without much change, so no cost outside the initial development no?
Well now it’s the time to update the code to work with a new version of a framework. Only the new target version of the framework is two major versions ahead of the one that was supported by the last patch, circa 5 years ago, and 4 major versions ahead of what the original version was developed to support. This support is also not provided by us, but by a dependency that was already deprecated when the original code was written. This dependency was vendored and modified to make the whole thing work.
Version 2 of this dependency was born, developed, deprecated, and abandoned in this time span. When it was abandoned, the migration path was to switch to a different dependency in the same problem space.
The original author of the module (and vendored dependency changes) is gone, and nobody knows how the module works. It’s also written incredibly messily.
So at this point the only solution is to rewrite the whole module.
The question then is: will a complete rewrite, by people that have no context of the original problem space or familiarity with the technology, cost more or less than it would have cost to gradually reduce the tech debt over the course of the last 8 years, by the original authors?
The only code that doesn’t accrue tech debt is not the one that doesn’t change, but that that will never change.
Now since whether a piece of code will never need to change is unknowable, it is unknowable whether unchanging code is accruing debt.
So as it often happens, if you don’t schedule maintenance for your code, your code will schedule maintenance on your behalf. And since by definition time for unscheduled maintenance is not scheduled, those issues will always fall at a bad moment.
I don’t know chief, I’m not convinced. Maintain your code.
My takeaway from the article was, in the author’s own words, “start with debt in code you’re about to change anyway”. That’s not to say you shouldn’t tackle technical debt in code that isn’t changing, rather it’s lower priority.
Yup, the longer you wait to update something, the higher the cost to eventually do that. I hate the “if ain’t broke don’t fix it” adage because of this. If I am the one who will eventually need to update it, you bet I will be “fixing” it more often than I have to.