"Software is getting slower more rapidly than hardware becomes faster."

Developers argue over whether “Wirth’s law” — that software gets slower faster than hardware gets faster — still holds, pointing to bloated web apps, Electron-based tools, heavy security suites and SaaS network hops as evidence that modern machines often feel no snappier than older ones. Many see the root cause in incentives: businesses reward rapid feature delivery and cross-platform reuse over profiling, algorithmic efficiency, and testing on low-end hardware, even though users routinely suffer from lag and resource-hungry clients. Others counter that SSDs, multicore CPUs and better tooling have made everyday computing noticeably faster overall, and that some modern stacks and libraries are in fact becoming more efficient.

Developer Hardware vs. User Reality

  • Many argue devs should regularly use low‑end machines or VMs throttled to “5th‑percentile” specs to feel real user pain and prioritize performance.
  • Others say this is counterproductive: modern dev stacks (IDE, Docker, DBs, Node, etc.) already strain good machines; slowing hardware just wastes expensive developer time.
  • Suggested compromise: fast dev box, but run the product itself in constrained VMs/phones or on dedicated low‑spec test machines.

Performance vs Features and Business Incentives

  • Repeated theme: businesses, not devs, set priorities; features and deadlines almost always beat performance.
  • Users often ask for new capabilities over speed, especially when features can save days while performance gains save hours.
  • Some worry this mirrors Jevons paradox: efficiency gains just get spent on more features and layers, not responsiveness.

Where Slowness Comes From

  • Frequent culprits mentioned: web bloat, Electron apps, excessive frameworks, SaaS/network hops, database N+1 queries, missing indexes, and over‑abstracted architectures.
  • Others point out that in enterprise, “custom stuff” can be worse than well‑chosen, efficient off‑the‑shelf components.
  • Security tools, telemetry, and “corporate‑ware” are described as major drains on I/O and CPU.

Is Wirth’s Law Actually True?

  • Some say yes: everyday apps, UIs, and simple operations often feel no faster despite orders‑of‑magnitude hardware gains; input lag examples and slow mobiles are cited.
  • Others counter with anecdotes of cheap modern machines feeling far faster than mid‑2000s PCs, especially with SSDs and better networks.
  • Several note the lack of rigorous longitudinal measurements; most evidence is anecdotal.

Optimization Culture and Languages

  • Some feel “optimization is the root of all evil” has been misused to justify never optimizing, and that many teams don’t profile or measure at all.
  • Others argue optimization is still valued where it matters (games, data tooling, performance‑oriented libraries like faster Python ecosystems), but business cases are often weak.
  • Thread highlights classic performance wins: better DB queries, indices, fewer network calls, and avoiding unnecessary abstraction layers.

Future Directions and Tools

  • People suggest network/CPU throttling tools, CI on slow hardware, and realistic datasets as practical ways to keep performance in check.
  • Opinions split on whether AI‑generated code will worsen bloat (faster “works‑but‑slow” output) or help optimize, depending on how it’s used.