[samhw]

It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

[foxfluff]

> It doesn't even require management to be unreasonable/intransigent/whatever. It's perfectly rational to write a prototype feature in a quick and hacky way, and then invest time in making it clean and extensible after you've validated user demand.

Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly."

Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.

[samhw]

Yeah, and that's when the complementary skill of knowing when to repay tech debt comes into the picture. I'm not sure what else you would be suggesting: that we should all build every experimental finger-in-the-air MVP as if it were core business-critical functionality, just so we don't have to be disciplined in judging when to repay tech debt?

[hobs]

For sure! And most of the time I would say spending 20x the time on a thing that you have no flipping idea is going to land is worse than technical debt, its called closing your doors.

I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!

[samhw]

Ah, yeah, I absolutely agree with you in that case. That's a very fair point. I'm sure there are lots of companies in which context it's not the engineer's decision at all, and therefore not their fault.