Laws of Software Engineering

Original Article ↗ Hacker News Discussion ↗

Overall reception of the “laws” site

  • Many see the collection as a nice visual index of aphorisms, but not a “great list.”
  • Calling them “laws” is widely criticized; they’re viewed as heuristics or observations, not inviolable rules.
  • Several note internal contradictions: you can cherry‑pick a law to justify almost any decision.
  • Some descriptions feel like “AI slop”; examples like the SpaceX story are seen as shallow or wrong.
  • The site going down due to hosting limits was viewed as ironic for something about software engineering.

Heuristics vs. real laws

  • Distinction drawn between:
    • Physical/theoretical laws (e.g., Amdahl, CAP in its narrow formal sense).
    • Observational laws (e.g., Hyrum’s, Greenspun’s, Brooks’s) that “tend to be true.”
    • Prescriptive aphorisms (KISS, YAGNI, DRY, SOLID, Postel, etc.) that require judgment.
  • Several argue the real skill is knowing when to break these rules and how to balance conflicting ones.

Specific principles heavily debated

  • Premature optimization / Knuth
    • Multiple commenters stress the full context: it’s about avoiding micro‑tuning before measuring, not ignoring performance or algorithmic complexity.
    • Complaint that the slogan is misused to excuse obviously slow designs and bad data‑structure choices.
    • Counterpoint: real premature optimization on imagined scale (microservices, complex infra, caching) causes massive waste.
  • DRY, abstractions, and coupling
    • DRY seen as frequently misapplied; merging “similar but not the same” code creates brittle abstractions.
    • Alternative framing: SPOT (Single Point of Truth) and “rule of three” (don’t abstract until you see three real uses).
    • Copy‑paste is defended as often cheaper than premature abstraction; abstractions are “expensive” and move complexity.
  • Postel vs. Hyrum
    • Being liberal in what you accept is criticized because it creates invisible contracts users depend on.
    • Suggested compromise: be strict on internal boundaries, more tolerant only when forced by legacy/unchangeable clients.

Design, complexity, and testing

  • Ousterhout’s ideas on encapsulating complexity and small interfaces are discussed; moving complexity into stable components is seen as a major design goal.
  • Some push “deletability” and modularity: aim for features that can be removed by deleting a file/dir with few connections.
  • Testing pyramid is challenged: too many low‑level tests can “pour molasses” into implementations; focus should be on stable interfaces.

Management, liability, and practice

  • Thread includes a long tangent on whether software engineers should be personally liable like civil engineers; others warn this is unrealistic given nation‑state attackers and existing compliance regimes.
  • Rewrites vs. refactors: strong advice to refactor legacy systems instead of “second‑system” rewrites that rarely succeed.

AI and changing context

  • Some feel these laws look dated in an AI‑assisted world; others report success using LLMs to explore faster implementations then porting ideas back into clean code.
  • Concern that LLM‑generated code and “vibe‑coded” sites repeat the same misapplications of these laws, just faster.

Resources and alternatives mentioned

  • Repeated praise for “A Philosophy of Software Design,” “The Pragmatic Programmer,” DDIA, and various classic CS texts.
  • Other curated collections (e.g., hacker‑laws, TAOUP) are cited as richer or less gimmicky.