Simplicity is an advantage but sadly complexity sells better (2022)

Complex software and gadgets often win in the market not because they work better, but because they signal flexibility, sophistication, job security, or “innovation” to buyers, managers, and reviewers. Commenters contrast this with the real advantages of simple solutions—easier adoption, reliability, and maintainability—while noting that incentives in enterprise sales, academia, promotion systems, and even consumer product design frequently reward visible complexity instead. Many argue that creating truly simple, robust systems is harder, slower, and less glamorous, so it is systematically undervalued despite delivering more long-term value.

Why Complexity Sells and Persists

  • Buyers often equate more features and knobs with “enterprise-grade” and flexibility, so bloated CMS/ERP/security products are easier to sell than lean tools.
  • Complexity helps build moats: vendor lock‑in, training revenue, certification ecosystems, and job security for specialists.
  • Some customers actively avoid adapting their workflows to off‑the‑shelf tools; they’d rather pay for heavy customization than change.
  • Complex, buggy systems can also be convenient excuses for missed deadlines or incompetence (“the software wouldn’t let me”).
  • In consumer products, aspirational buyers tolerate gimmicky, complex UIs if they signal luxury, status, or “innovation.”

Simplicity vs. Flexibility and “Real” Requirements

  • Many note that “simple” solutions can be inflexible or suboptimal once you consider diverse use cases, integration needs, and evolving requirements.
  • Organizations often prefer one big configurable system over many small focused ones, even if that means lots of unused features.
  • There’s disagreement on what “simple” even means; what’s simple for an expert can be complex for the average team.

Incentives in Companies and Academia

  • Promotion systems that reward “solving complex problems” incentivize engineers to seek or manufacture complex problems and solutions.
  • Committees often can’t distinguish inherently hard problems from overengineered ones, so visible technical complexity becomes a career asset.
  • Academic reviewers frequently penalize methods that are too simple or composed of existing parts, even though simple methods are easier to adopt and reason about.

UI and Product Examples

  • Microwaves, blenders, and car dashboards illustrate the “Microwave Problem”: most people use a tiny subset of controls, yet minimal UIs are hard to sell.
  • Some argue marketing can flip this by selling “removal of cruft” as a premium feature; others say people also genuinely value having options.
  • Car UX debates: some praise touchscreen‑heavy EVs as simpler overall; others find them dangerous and unwieldy compared to physical controls.

Engineering Practice and Over‑Complex Stacks

  • Many examples of unnecessary “scalabilitization”: Kubernetes for tiny loads, Cassandra/DynamoDB where a single relational DB would suffice, Hadoop/K8s clusters that never justified their cost.
  • Frontend/JS and DevOps are repeatedly cited as domains where layered frameworks and fads create huge incidental complexity.
  • Several commenters emphasize iterative refinement (Kaizen), small impactful changes, and opinionated/simple tools as antidotes, while warning that simple solutions are often the hardest to design.