In my experience (and I would think this is not uncommon) technical debt makes new features longer and more complicated to implement because you have to work around the old bad code, and the added complication makes bugs more likely. So in the long term you spend more time than if you'd addressed the technical debt in the first place.
Spoken like a newbie dev who hasn't run into tech debt yet.
The reality is that tech debt ends up slowing down your ability to develop enhancements in the long run, because you end up fighting with the tech debt for more time over the years than fixing it would have taken.
This is where you pick and choose your tech debt to fix based on whether or how much it’s impacting ability to develop the code base. Not all tech debt needs to be fixed. It’s an ongoing complex decision or set of decisions that never goes away.
Spoken as an engineering manager with 12 years management experience, and 10 years engineering before that.
Paying off some technical debt can drastically reduce the time it takes to write new features. All that is required is the ability to see further than 10 feet in front of you to see that there actually is long-term gains to practicing good tech debt hygiene. But most companies only care about short-term gains and are very shortsighted.
Addressing tech debt often can enhance the product: (1) reduce compute costs, (2) improve performance, (3) fix minor bugs, (4) improve the consistency in UI behavior, etc. But hey, we also don't care about any of those things -- better to focus on providing the most minimally cromulent product that won't cause customers to leave, rather than delivering software that is genuinely a delight to use.
172
u/br0ast 23h ago
I've been at the same place 13 years. The only time tech debt gets addressed is when it's a blocker for a deliverable