laws-of-software-engineering

name	laws-of-software-engineering
description	Apply the 56 canonical laws of software engineering (Conway's, Brooks's, Hyrum's, CAP, DRY, KISS, YAGNI, SOLID, Pareto, Goodhart's, Murphy's, etc.) when discussing architecture, team structure, planning, estimation, code quality, scale, design trade-offs, or engineering decisions. Use to name forces at play, warn about known pitfalls, or justify trade-offs with a shared vocabulary.

Laws of Software Engineering

A catalog of 56 named principles that describe recurring forces in software systems, teams, and decisions. Source: https://lawsofsoftwareengineering.com/

When to use

• Diagnosing why a project, team, or codebase behaves the way it does
• Arguing for or against a design/process/hiring decision with an established name
• Estimating, planning, or warning about predictable failure modes
• Code review, architecture review, retros, post-mortems
• Explaining trade-offs to non-engineers or junior engineers

Cite a law by name when it adds clarity. Don't force-fit — if no law applies, skip it.

How to use

1. Scan the one-line index below to spot laws relevant to the situation.
2. Load the matching category reference (references/<category>.md) for overview, takeaways, examples, and origins.
3. Cite law by name + one-line summary; link to the full entry if depth is needed.

Index (56 laws)

Architecture — references/architecture.md

• Conway's Law — Systems mirror the org's communication structure.
• Hyrum's Law — With enough users, every observable behavior becomes a dependency.
• Gall's Law — Complex systems that work evolved from simple ones that worked.
• Law of Leaky Abstractions — All non-trivial abstractions leak.
• Tesler's Law — Complexity is conserved; it can only be shifted, not removed.
• CAP Theorem — Pick 2 of: consistency, availability, partition tolerance.
• Second-System Effect — Successful v1s spawn overengineered v2s.
• Fallacies of Distributed Computing — 8 false assumptions about networks.
• Law of Unintended Consequences — Changing a complex system always surprises you.
• Zawinski's Law — Every program expands until it can read mail.

Teams — references/teams.md

• Brooks's Law — Adding people to a late project makes it later.
• Dunbar's Number — ~150 stable relationships is the cognitive ceiling.
• Ringelmann Effect — Individual productivity drops as group size grows.
• Price's Law — √N of participants do 50% of the work.
• Putt's Law — Those who understand tech don't manage it; those who manage don't understand it.
• Peter Principle — People rise to their level of incompetence.
• Bus Factor — Min number of people whose loss would kill the project.
• Dilbert Principle — Incompetents get promoted to limit their damage.

Planning — references/planning.md

• Knuth's Premature Optimization — Premature optimization is the root of all evil.
• Parkinson's Law — Work expands to fill the time available.
• Ninety-Ninety Rule — The first 90% takes 90% of the time; so does the last 10%.
• Hofstadter's Law — It always takes longer, even accounting for Hofstadter's Law.
• Goodhart's Law — When a measure becomes a target, it stops being a good measure.
• Gilb's Law — Anything worth quantifying can be measured somehow, better than not.

Quality — references/quality.md

• Boy Scout Rule — Leave the code better than you found it.
• Murphy's Law — Anything that can go wrong, will.
• Postel's Law — Be strict in what you send, lenient in what you accept.
• Broken Windows Theory — Don't leave small code problems unrepaired.
• Technical Debt — Shortcuts are loans with compounding interest.
• Linus's Law — Given enough eyeballs, all bugs are shallow.
• Kernighan's Law — Debugging is twice as hard as writing the code.
• Testing Pyramid — Many unit tests, fewer integration, very few UI tests.
• Pesticide Paradox — Repeated identical tests find fewer new bugs.
• Lehman's Laws — Living software must evolve, and evolution has predictable limits.
• Sturgeon's Law — 90% of everything is crap.

Scale — references/scale.md

• Amdahl's Law — Parallel speedup is capped by the serial fraction.
• Gustafson's Law — Scale the problem to keep parallel resources busy.
• Metcalfe's Law — Network value grows with the square of users.

Design — references/design.md

• YAGNI — Don't build functionality until it's needed.
• DRY — Every piece of knowledge has one authoritative representation.
• KISS — Keep it simple.
• SOLID — 5 OO design guidelines: SRP, OCP, LSP, ISP, DIP.
• Law of Demeter — Only talk to your immediate friends.
• Principle of Least Astonishment — Behave as users/devs expect.

Decisions — references/decisions.md

• Dunning-Kruger Effect — Low skill breeds high confidence.
• Hanlon's Razor — Don't attribute to malice what carelessness explains.
• Occam's Razor — Prefer the simplest explanation.
• Sunk Cost Fallacy — Past investment isn't a reason to continue.
• Map Is Not the Territory — Models aren't reality.
• Confirmation Bias — We favor info that confirms existing beliefs.
• Hype Cycle / Amara's Law — Overestimate short-term impact, underestimate long-term.
• Lindy Effect — The longer something has survived, the longer it likely will.
• First Principles Thinking — Decompose to fundamentals; rebuild reasoning from there.
• Inversion — Work backward from failure; ask what would break this.
• Pareto Principle (80/20) — 80% of outcomes from 20% of causes.
• Cunningham's Law — Best way to get the right answer is to post the wrong one.

Usage tips

• Cite by name, not by authority. "This is Conway's Law" > "A book I read says…"
• Pair laws that counterbalance. Parkinson ↔ Hofstadter, Goodhart ↔ Gilb, Amdahl ↔ Gustafson, YAGNI ↔ Gall.
• Don't stack 5 laws in one response. One or two well-chosen names do more than a lecture.
• Beware Goodhart: if you use these laws as a checklist to grade others, they stop being useful observations.

References

• references/architecture.md — 10 laws on systems, abstractions, distribution
• references/teams.md — 8 laws on org dynamics and people
• references/planning.md — 6 laws on estimation, deadlines, metrics
• references/quality.md — 11 laws on code quality, testing, evolution
• references/scale.md — 3 laws on parallelism and network effects
• references/design.md — 6 laws on code structure and interfaces
• references/decisions.md — 12 laws on reasoning and cognitive biases