But, after having witnessed, and having committed, countless acts of perfecting something until it died on the vine, I would consider, "This hack is hard to change because so very many people are paying us money in return for the privilege of relying on it," to be a very nice problem to have.
the pendulum can swing too far in either direction. but pumping out features with no regard for how they will be maintained is a recipe for lower velocity and less stability in the future.
> pumping out features with no regard for how they will be maintained
That doesn't seem to be the position that's being advanced here. TFA, for example, starts out talking all about the author fell in love with React for its easy maintainability, before moving on to the need to make some tweaks for the sake of user experience, and finally ending by proposing a design that is based on a fairly principled set of design tradeoffs.
And the parent commenter, at least to my reading, isn't saying, "phooey, who cares about maintainability," they're saying that, while they don't like React, they do have to acknowledge that there is pragmatic value in it not being so rigid that you can't just grind out the code when business realities mean that that's what you need to do.
Long story short, if what you're trying to advocate is a flexible, middle-path-type approach, I don't know that this is the best place to go searching for a debate on the subject.
true, but for me writing highly architected features that take 3x or more time to write just to steer away because of business needs (i.e. doesn't sell) seems to me more painful.
But, after having witnessed, and having committed, countless acts of perfecting something until it died on the vine, I would consider, "This hack is hard to change because so very many people are paying us money in return for the privilege of relying on it," to be a very nice problem to have.