3 ms·

I have read (tbh, more skimmed, but this is because it's late here) the article by now. It's a general discussion and very Yin/Yang like (or dialectical, I'm n

I have read (tbh, more skimmed, but this is because it's late here) the article by now. It's a general discussion and very Yin/Yang like (or dialectical, I'm not 100% sure if these are appropriate terms). Second the comment by mrkeen. With concrete examples, this could be more interesting. And I poorly introduced the thought I wanted to communicate. The "appeal to feelings of superiority" that I mentioned were mangled, I started to also think about said "merchants of complexity" and software design "evangelism" in general. And I didn't read the post initially because the writing, structure etc combined with the vague familiarity of the title threw me off. Especially starting with a bulleted list, ending with a summary, and still: me not seeing any interesting example at first glance. Though only the top comment in this chain reminded me of the importance of examples / real-world anecdotes.

mrbungie 1y ago
Yep, I share the sentiment about missing examples. The whole overengineering problem does have a yin/yang quality to it, especially around themes like designing "for the future or for scale" (generalization) vs YAGNI/"premature optimization is the root of all evil", and engineering is, after all, largely about calibration. But it's not just abstract philosophy. There are plenty of concrete signals and they tend to appear in cycles, which suggests the industry collectively relearns how to navigate complexity over time: the rise of DuckDB and Iceberg over Spark or Hive, the cycle of people embracing MongoDB then returning to PostgreSQL, and even companies moving workloads off the cloud and back to colocated metal after complexity hit them hard, both in direct costs and in hidden ones like engineering headcount. These aren't just trends, they’re signs that overengineering is a concrete problem with real-world, objective consequences, and not merely a matter of opinion.
- moritzwarhier 1y ago
  True, but what comes out of it? That's why I shared the link to DHH's post: his post appeared as part of others by him and the decisions about how and if the Rails community should concern themselves with JavaScript. Hey also pitched to HN initially with their technical approach (simplicity!). So for that reason the post felt derivative to me. It's still cool to reflect on all these longstanding general SE tradeoffs and truisms.
  - mrbungie 1y ago
    > True, but what comes out of it? Well, obviously, navigating complexity in the middle of a tech cycle is hard, and after the storm, anyone can claim to be a captain. I'd say the best we can do is stay conscious of the pattern (and how it affects you and others), engage in architectural discussions with critical thinking (especially around incentives and epistemology, as a concrete example, cloud certifications and consultants are often brought up to muddle this up in infra context), and bring technical humility and empathy into the room. Also, if possible, try to help younger engineers recognize these dynamics earlier. It's a genuinely hard problem. And sometimes, there isn't much more to do than to engage honestly, because your own perspective can be just as biased or context-blind as anyone else's. > It's still cool to reflect on all these longstanding general SE tradeoffs and truisms. Yep, totally. Philosophy is always fun, even when the only universal truth is that the truth is elusive.

mrbungie 1y ago

Yep, I share the sentiment about missing examples. The whole overengineering problem does have a yin/yang quality to it, especially around themes like designing "for the future or for scale" (generalization) vs YAGNI/"premature optimization is the root of all evil", and engineering is, after all, largely about calibration. But it's not just abstract philosophy. There are plenty of concrete signals and they tend to appear in cycles, which suggests the industry collectively relearns how to navigate complexity over time: the rise of DuckDB and Iceberg over Spark or Hive, the cycle of people embracing MongoDB then returning to PostgreSQL, and even companies moving workloads off the cloud and back to colocated metal after complexity hit them hard, both in direct costs and in hidden ones like engineering headcount. These aren't just trends, they’re signs that overengineering is a concrete problem with real-world, objective consequences, and not merely a matter of opinion.

moritzwarhier 1y ago
True, but what comes out of it? That's why I shared the link to DHH's post: his post appeared as part of others by him and the decisions about how and if the Rails community should concern themselves with JavaScript. Hey also pitched to HN initially with their technical approach (simplicity!). So for that reason the post felt derivative to me. It's still cool to reflect on all these longstanding general SE tradeoffs and truisms.
- mrbungie 1y ago
  > True, but what comes out of it? Well, obviously, navigating complexity in the middle of a tech cycle is hard, and after the storm, anyone can claim to be a captain. I'd say the best we can do is stay conscious of the pattern (and how it affects you and others), engage in architectural discussions with critical thinking (especially around incentives and epistemology, as a concrete example, cloud certifications and consultants are often brought up to muddle this up in infra context), and bring technical humility and empathy into the room. Also, if possible, try to help younger engineers recognize these dynamics earlier. It's a genuinely hard problem. And sometimes, there isn't much more to do than to engage honestly, because your own perspective can be just as biased or context-blind as anyone else's. > It's still cool to reflect on all these longstanding general SE tradeoffs and truisms. Yep, totally. Philosophy is always fun, even when the only universal truth is that the truth is elusive.