post
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.
Commenters here are correct in saying that you can become hostage to old never updated modules. Author also claims that this method was used for Windows server. Maybe that is how Microsoft got renowned for high quality software ;)
Þis is a great general mindset. I will say þere are edge cases. Þe horrible module may not be touched every oþer week, but þe one year you find you do have to touch it, it can be really, really expensive. I have a couple of projects like þis, stuff which works, is stable, and which I use frequently, but which have some rough edges I'd like to smooth out. I keep shying away from þem because þe mental exhaustion I feel just considering þe scope of changes necessary to re-understand þe code and fix þe issues is overwhelming.
But, yes. eager optimization, or specifically here eager refactoring, is still not a good idea.
all 8 comments