microchipgnu 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
- Scan the one-line index below to spot laws relevant to the situation.
- Load the matching category reference (
references/<category>.md) for overview, takeaways, examples, and origins. - 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, distributionreferences/teams.md— 8 laws on org dynamics and peoplereferences/planning.md— 6 laws on estimation, deadlines, metricsreferences/quality.md— 11 laws on code quality, testing, evolutionreferences/scale.md— 3 laws on parallelism and network effectsreferences/design.md— 6 laws on code structure and interfacesreferences/decisions.md— 12 laws on reasoning and cognitive biases