7 ms·

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of g

by smt88 19d ago

Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise. Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.

ryanisnan 19d ago
Sure but it's a spectrum. Surely some choices will age much more poorly than others.
satvikpendem 19d ago
100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.
- smt88 19d ago
  You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.
  - satvikpendem 19d ago
    Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.
mostlysimilar 19d ago
> RoR and so poorly planned that it’s still biting Microsoft on a regular basis. Disagree. The RoR front end was way more stable and usable than the mess they have made now.
- smt88 19d ago
  The issues are with the Ruby backend. RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
  - xp84 19d ago
    > RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is such a "poor carpenter blaming his tools" take. RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time. By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.
ashwinsundar 19d ago
Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well
- smt88 19d ago
  Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless. This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
  - ashwinsundar 19d ago
    Sir, this is a Wendy's
- xp84 19d ago
  calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.
  - ashwinsundar 19d ago
    bikeshed
    - euroderf 19d ago
      pronounced "by-kesht"
officialchicken 18d ago
Is it though? It doesn't need to be perfect to last. Good engineering practices certainly embrace timeless concepts. I understand if you are working in a feature-factory, but creating inheritable code should be given more consideration however much programmers dislike thinking about things like ROI.

by smt88 19d ago

ryanisnan 19d ago

Sure but it's a spectrum. Surely some choices will age much more poorly than others.

satvikpendem 19d ago

100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.

smt88 19d ago
You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.
- satvikpendem 19d ago
  Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.

mostlysimilar 19d ago

> RoR and so poorly planned that it’s still biting Microsoft on a regular basis. Disagree. The RoR front end was way more stable and usable than the mess they have made now.

smt88 19d ago
The issues are with the Ruby backend. RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
- xp84 19d ago
  > RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is such a "poor carpenter blaming his tools" take. RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time. By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.

ashwinsundar 19d ago

Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well

smt88 19d ago
Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless. This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
- ashwinsundar 19d ago
  Sir, this is a Wendy's
xp84 19d ago
calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.
- ashwinsundar 19d ago
  bikeshed
  - euroderf 19d ago
    pronounced "by-kesht"

officialchicken 18d ago

Is it though? It doesn't need to be perfect to last. Good engineering practices certainly embrace timeless concepts. I understand if you are working in a feature-factory, but creating inheritable code should be given more consideration however much programmers dislike thinking about things like ROI.