[Pet_Ant]

Tech debt means the next is feature 5% more expensive... compounding.

I'm now on a project that has spent 2 months (10 people months) to add a box to the checkout screen for the cashier to enter a special discount amount. No business logic, straight pass through. Originally, I thought it could be done in a week by one person: nope. Once you get in the weeds, it takes this.

This is now 4000% more expensive (literally, do the math) because of compound interest. Tell me that isn't valuable to the customer.

[wizofaus]

If that were the only reason tech debt were bad, I wouldn't worry about it so much. But I'd estimate at least 25% of the bugs in our software come about because of existing tech-debt - developers make reasonable assumptions about how things work when implementing new features (or fixing other bugs), but because of hidden tech debt, those assumptions end up not being true in significant corner cases. A classic example is when code is originally written for a very specific purpose, then later gets "somewhat" generalised in order to support a wider-range of cases - but lots of the original code that only made sense for the initial implementation is left in place, instead of properly separating out the "specific-case" code and the shared logic. Years later devs (not involved in the original development) reasonably assume it's intended to act as a general purpose component and use it as such, only to find it starts misbehaving because it was never properly refactored from its original implementation.

[ilyt]

I feel like way too many people here haven't exactly experienced a long term project. Spending extra 20% now to get it right always pays off on anything longer than say a year or two. Even spending 50% or 100% sometimes does.