[quadrifoliate]

> Like the idea of shipping functional-but-ugly code is somehow totally unacceptable for some reason (even when it's obvious the "pretty" version isn't even future-proofed or appreciably better). And the excuse is usually "Well we'll never have time to fix it".

You are thinking of it from your team's perspective. We have some shipping code, we just need to clean it up and architect it properly to do the exact same thing! Sounds reasonable, right?

Now think about it from the point of view of the customer that's paying you money for the feature. Do you think they would want a feature that has "architect for real" in the roadmap after they pay you money for it? Would you pay money for such software? [Yes, they don't need to know, but think about what if they did.]

How this actually plays out in the real world is that customers pay money based on a somewhat vague promise of features in the future. If your "architect for real" delays the launch of those features (as it likely will, these 'simple refactors' have a habit of becoming not-so-simple), then it's bad look. So customer-focused teams try to get it right the first time and deliver a cohesive, architected feature.

I did say "try" above. Like all real software, it's impossible to be perfect. But "we'll do it for real afterwards" attitudes like yours often tend to produce friction, and this is my attempt to explain why.

[garrickvanburen]

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.

[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.

[pixl97]

> 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.

[aleph_minus_one]

> Now think about it from the point of view of the customer that's paying you money for the feature. Do you think they would want a feature that has "architect for real" in the roadmap after they pay you money for it? Would you pay money for such software? [Yes, they don't need to know, but think about what if they did.]

At least I am this kind of person. :-) I also believe that on HN, you would find some people who are also of this kind of breed.

The problem rather is that many customers do not value this.