Laws of Software Engineering
A curated website of “laws of software engineering” prompts debate over whether such aphorisms are useful guidance or misleading pseudo-laws. Commenters note that many entries are contradictory, context‑dependent and often misapplied (e.g., Knuth’s “premature optimization,” DRY, YAGNI, Postel’s Law, SOLID), arguing they should be treated as heuristics rather than rules. Several emphasize that real engineering judgment lies in knowing when to break these sayings, how to balance simplicity, performance, and abstraction in practice, and how new factors like AI-generated code and modern infrastructure change the relevance of older principles.
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.