Why do we keep gravitating toward complexity?

Original Article ↗ Hacker News Discussion ↗

Motivations for Complexity

  • Status, ego, and identity: complex systems can signal intelligence, pad CVs, and create job security (“only I understand this”).
  • Dopamine and boredom: solving intricate problems feels good; bored developers add complexity to make work interesting.
  • Enjoyment of “well‑arranged complexity”: some people derive the same pleasure from intricate systems that others get from art or comfort.
  • Resume and fashion: teams copy big-company stacks (React, Kubernetes, etc.) to feel modern and employable, even when overkill.

Accidental and Structural Sources

  • Prototypes shipped as products: early “just make it work” code is never redesigned; layers of patches accumulate.
  • Local fixes vs redesign: it’s cheaper to “add one more check” than to revisit top-level abstractions; entropy wins.
  • Conway’s Law and org design: arbitrary team boundaries and business constraints produce fractured, complex architectures.
  • Lack of visibility and pricing: software complexity is invisible and often doesn’t show up as clear per-unit cost, unlike in hardware.

Simplicity Is Hard Work

  • Many argue simplicity is more difficult: it requires deep domain understanding, iterative exploration, refactoring, and saying “no” to features and tools.
  • Good design often looks trivial from the outside, so its value is under-rewarded compared to visibly complex work.
  • True skill is matching solution complexity to problem complexity (e.g., identity systems legitimately need messy logic; many CRUD apps don’t).

React vs “Sprinkled JavaScript”

  • One camp agrees with the article: React-style stacks introduce unnecessary concepts (state soup, build pipelines) for simple pages; modern browser APIs and “just HTML+JS” are often enough.
  • The opposing camp counters:
    • Frameworks reduce developer complexity for nontrivial, changing apps (state, routing, CI/CD, modularity, large teams).
    • Ad‑hoc “sprinkles” tend to devolve into unstructured, harder-to-maintain code; you end up reinventing a worse React.
    • Tool internals may be complex, but usage can be simple—like vending machines or power tools.
  • Some criticize the article for lacking concrete misuse examples and for underestimating current browser/JS realities; others think it rightly calls out using React for static sites.

Pyramids and Inevitability

  • Pyramids analogy sparks debate:
    • Supporters: they had a single, immutable purpose; software changes constantly, so complexity is inevitable.
    • Others focus on purpose: pyramids show that large “complex” undertakings can be justified if the goal is clear, unlike purposeless architectural pyramids in code.
  • Several point out that long-lived systems will accrete complexity; the key is stewardship, not fantasy about a forever-simple codebase.