It's helpful to reinforce the need for simplicity. But more helpful would be some principles. Like: WHY is hardware and software scaling so different? - Hard

It's helpful to reinforce the need for simplicity. But more helpful would be some principles. Like: WHY is hardware and software scaling so different? - Hardware has been adding parallelism and reducing constraints, i.e., reducing interactions - Software has been adding interactions and building abstractions that hide physical costs, which hides combinatorial growth of compute. Developers often don't even know a call depends on the network or the filesystem, no less how some library interacts with another. Outside of internet-scale algorithms, systems remain mostly usable. - Companies can mostly transition hardware (via HAL's) - x86 to ARM, DDR4 to 5, multiple network adapters - but they fiercely guard and differentiate on software (due to high switching costs to build expertise in humans), so we get Go and Android and native containers and a million other variations because companies can't be beholden to software vendors. Also, the quality problem is entirely distinct. There are real-time trading platforms with near-optimal speeds because speed matters most there. For banking web sites, low maintenance and support costs matter most, so the UI is dumb and constraining. Difficult software can make economic sense. Finally, "bloat" is what you say to big-bank clients who've proliferated javascript dependencies, when you want to sell them on Go as the do-everything-yourself language. It could also be framing a choice between a small expert (US) team and a large distributed (outsourced) team, when you want to show why less can be more. The scarecrow term carries emotion and an intuition without being subject to counter-analysis.