Hacker News new | ask | show | jobs
by garrickvanburen 1068 days ago
Also from the customers perspective, it works. It solves their problem.

Touching it - even to clean it up and make it more maintainable - introduces risk that it won’t work.

Lean Manufacturing principles suggest the customer only pays for value. Making it more maintainable isn’t obviously valueable to the customer.

2 comments

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.

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.
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.
> it works. It solves their problem.

Eh, lets add "For a time"

In my experience it tends to work like this. New feature is added. Client tests it and it works great. Client has a few more subrequests to make the feature excellent for them that take a month or two to implement. In the meantime huge amounts of data are building up in the database. The even newer features get implemented and suddenly the customer system explodes in a ball of fire. Turns out they are taking those new features and doing things you never expected with other existing features and now your system isn't performant enough. Now the entire process of adding new features for other clients has stopped as 'redneck architect' the system to a point it doesn't fall over, all while the customer is pissed.