4 ms·

> but if the code you are writing is for a new product that is still trying to find a market-fit spending a lot of time in the architecture of something that co

> but if the code you are writing is for a new product that is still trying to find a market-fit spending a lot of time in the architecture of something that could drastically change doesn’t make much sense to me. "Nothing is more permanent than a temporary solution"

mumblemumble 6y ago
It's true. 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.
- leeoniya 6y ago
  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.
  - _benj 6y ago
    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.
  - mumblemumble 6y ago
    > 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.

mumblemumble 6y ago

It's true. 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.

leeoniya 6y ago
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.
- _benj 6y ago
  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.
- mumblemumble 6y ago
  > 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.