3 ms·

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

by samhw 5y ago

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.

hobs 5y ago
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 5y ago
  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.
foxfluff 5y ago
> 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 5y ago
  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?

by samhw 5y ago

hobs 5y ago

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 5y ago
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.

foxfluff 5y ago

> 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 5y ago
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?