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 cost of a piece of debt is its messiness multiplied by how often you go near it. A horrible module that hasn’t changed since 2023 costs almost nothing today. You’re not reading it or extending it. Refactoring it is paying down a loan that isn’t accruing interest. Meanwhile the mediocre little helper that 40 features lean on, the one edited every other week, is quietly the most expensive code you own. It’s usually not on anyone’s list because it doesn’t look scary.
I had not thought about tech debt in this way before. It makes perfect sense to focus on paying off the tech debt where you spend the majority of your time working, and hence accruing interest on.
Definitely a nice way to feel in control but not the full picture here.
I maintain solo a largish CQRS created 10 years ago, there are some design flaws (the original author was learning the actor model and used it for practice for the Command part and you can guess how it turned up) + things got out of date (it uses Elasticsearch 1.7 for example), it’s a ticking time bomb keeping me awake at night; I have no way to convince the business people I need a few weeks to bring it back up to speed. The Elasticsearch 1.7 client is logging a lot of warnings regarding inner transport layer (TLS related), a plugin disappeared entirely from the internet and we replaced it with some expensive hacks,… all recent hires are 100% dependent on Claude. At this point I just wish I will be working somewhere when this explodes. Just to say running-untouched-systems can become massive ticking time bombs and not just grow tech debt.
Yeah I wish it was a more common understanding that your code files are just documents that describe the processes of your business.
If you have a process that nobody dares to touch anymore because it’s too messy, you have a document that holds part of your business hostage.
It forces you to stagnate in the areas described by the document, and you can work around that for quite a while, but that doesn’t mean it doesn’t do any harm.
I had not thought about tech debt in this way before. It makes perfect sense to focus on paying off the tech debt where you spend the majority of your time working, and hence accruing interest on.
Definitely a nice way to feel in control but not the full picture here.
I maintain solo a largish CQRS created 10 years ago, there are some design flaws (the original author was learning the actor model and used it for practice for the Command part and you can guess how it turned up) + things got out of date (it uses Elasticsearch 1.7 for example), it’s a ticking time bomb keeping me awake at night; I have no way to convince the business people I need a few weeks to bring it back up to speed. The Elasticsearch 1.7 client is logging a lot of warnings regarding inner transport layer (TLS related), a plugin disappeared entirely from the internet and we replaced it with some expensive hacks,… all recent hires are 100% dependent on Claude. At this point I just wish I will be working somewhere when this explodes. Just to say running-untouched-systems can become massive ticking time bombs and not just grow tech debt.
Yeah I wish it was a more common understanding that your code files are just documents that describe the processes of your business.
If you have a process that nobody dares to touch anymore because it’s too messy, you have a document that holds part of your business hostage.
It forces you to stagnate in the areas described by the document, and you can work around that for quite a while, but that doesn’t mean it doesn’t do any harm.