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.