🪴 PG Notes

Source — Laws of Software Engineering

11 min read

Source — Laws of Software Engineering

Author / curator: Dr. Milan Milanović URL: https://lawsofsoftwareengineering.com/ Format: Curated index of ~50 one-line “laws” organised by domain. Raw file: raw/Laws of Software Engineering.md

What This Source Is

A compact reference site that collects the most-cited principles, heuristics, and biases that shape software engineering — from organisational dynamics (Conway, Brooks) through architecture (Hyrum, CAP, Gall) and quality (Murphy, Postel, Linus) to decision-making (Pareto, Occam, Hanlon, Dunning-Kruger). Each entry on the site is a headline law with a paragraph of explanation; the raw file ingested here contains only the headlines.

These “laws” are not physical laws. They are observed regularities — empirical patterns that keep showing up across teams, codebases, and decades. Most originated outside software (Parkinson in civil service, Peter in management, Pareto in Italian land ownership) and were adopted because engineering is where their edges bite hardest. The value of the collection is as a checklist of priors — before you design a system, choose a metric, add staff, or rewrite from scratch, these are the forces you’re implicitly betting against.

Organising Principle

The site groups laws into seven domains, and this wiki preserves that grouping:

DomainWhat It’s About
TeamsOrganisational dynamics; the sociology of software
PlanningEstimation, scheduling, goals, and metrics
ArchitectureSystem structure, dependencies, distribution, complexity
QualityDefects, tests, maintenance, evolution
DesignAbstraction, coupling, simplicity, naming
DecisionsCognitive biases and reasoning tools
ScalePerformance, parallelism, network effects

All 50 Laws, Grouped

Flagged entries (★) are marked by the curator of this wiki as especially high-signal or cross-connected to other wiki threads. Laws with their own wiki pages are wikilinked; the rest are one-line stubs you can promote later.

Teams

  • ★ Conway’s Law — Organisations design systems that mirror their own communication structure.
  • Brooks’s Law — Adding manpower to a late software project makes it later.
  • Dunbar’s Number (stub) — Cognitive limit of ~150 stable relationships per person.
  • Ringelmann Effect (stub) — Individual productivity decreases as group size increases.
  • Price’s Law (stub) — The square root of the total number of participants does 50% of the work.
  • Putt’s Law (stub) — Those who understand technology don’t manage it, and those who manage it don’t understand it.
  • Peter Principle (stub) — Employees rise to their level of incompetence.
  • Bus Factor (stub) — Minimum number of team members whose loss would put the project in serious trouble.
  • Dilbert Principle (stub) — Companies promote incompetent employees to management to limit the damage they can do.

Planning

  • Parkinson’s Law — Work expands to fill the time available for its completion.
  • The Ninety-Ninety Rule (stub) — The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.
  • ★ Hofstadter’s Law — It always takes longer than you expect, even when you account for Hofstadter’s Law.
  • ★ Goodhart’s Law — When a measure becomes a target, it ceases to be a good measure.
  • Gilb’s Law (stub) — Anything you need to quantify can be measured in some way better than not measuring it.
  • Knuth’s Optimization Principle (stub) — Premature optimization is the root of all evil.

Architecture

  • ★ Hyrum’s Law — With enough users, all observable behaviours of your system will be depended on by somebody.
  • Gall’s Law (stub) — A complex system that works is invariably found to have evolved from a simple system that worked.
  • Law of Leaky Abstractions (stub) — All non-trivial abstractions are to some degree leaky.
  • Tesler’s Law (Conservation of Complexity) (stub) — Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.
  • CAP Theorem — A distributed system can guarantee only two of: consistency, availability, partition tolerance.
  • Second-System Effect (stub) — Small successful systems are followed by overengineered, bloated replacements.
  • Fallacies of Distributed Computing (stub) — Eight false assumptions new distributed-system designers make (network is reliable, latency is zero, bandwidth is infinite, etc.).
  • Law of Unintended Consequences (stub) — Whenever you change a complex system, expect surprise.
  • Zawinski’s Law (stub) — Every program attempts to expand until it can read mail.

Quality

  • The Boy Scout Rule (stub) — Leave the code better than you found it.
  • Sod’s Law — Anything that can go wrong will go wrong.
  • Postel’s Law (stub) — Be conservative in what you do, be liberal in what you accept from others.
  • Broken Windows Theory (stub) — Don’t leave broken windows (bad designs, wrong decisions, poor code) unrepaired.
  • Technical Debt (stub) — Everything that slows us down when developing software.
  • Linus’s Law (stub) — Given enough eyeballs, all bugs are shallow.
  • Kernighan’s Law (stub) — Debugging is twice as hard as writing the code in the first place.
  • Testing Pyramid (stub) — Many fast unit tests, fewer integration tests, a small number of UI tests.
  • Pesticide Paradox (stub) — Repeatedly running the same tests becomes less effective over time.
  • Lehman’s Laws of Software Evolution (stub) — Software that reflects the real world must evolve, and that evolution has predictable limits.
  • Sturgeon’s Law (stub) — 90% of everything is crap.

Design

Decisions

  • Dunning-Kruger Effect — The less you know about something, the more confident you tend to be.
  • Hanlon’s Razor — Never attribute to malice that which is adequately explained by stupidity or carelessness.
  • Occam’s Razor — The simplest explanation is often the most accurate one.
  • Sunk Cost Fallacy (already in wiki) — Sticking with a choice because of prior investment even when walking away helps.
  • The Map Is Not the Territory (stub) — Our representations of reality are not the same as reality itself.
  • Confirmation Bias (stub) — A tendency to favour information that supports existing beliefs.
  • Hype Cycle & Amara’s Law (stub) — We overestimate technology in the short run and underestimate it in the long run.
  • The Lindy Effect — The longer something has been in use, the more likely it is to continue being used.
  • first-principles-thinking (already in wiki) — Break a complex problem into basic blocks and build up.
  • inversion (already in wiki) — Solve a problem by considering the opposite outcome and working backward.
  • 20 Rule) — 80% of problems come from 20% of causes.
  • Cunningham’s Law — The best way to get the correct answer on the Internet is not to ask a question, it’s to post the wrong answer.

Scale

  • Amdahl’s Law (stub) — Parallel speedup is limited by the serial fraction.
  • Gustafson’s Law (stub) — Significant parallel speedup is possible by scaling the problem size.
  • Metcalfe’s Law (stub) — The value of a network is proportional to the square of the number of users.

Key Insights (curator-flagged for this wiki)

Per user direction, these four are treated as the high-signal entries in this collection:

Conway’s Law — architecture mirrors org chart

The most cited law in the set. If four teams build a compiler, you will get a four-pass compiler. The “inverse Conway manoeuvre” (design the org chart that would produce the system you want, then build the system) is how large platform efforts now deliberately exploit it. Connects to founder mode: founder-led companies collapse communication hierarchies, so their systems tend to be more integrated; big-company systems are more modular because the orgs are. See conways-law.

Hyrum’s Law — every observable becomes a contract

Articulated by Google engineer Hyrum Wright: with enough users, every behaviour of your system — documented or not — will be depended on by somebody. This is the empirical reason backwards compatibility is hard: you cannot enumerate what users depend on; they depend on accident, performance timing, error text, iteration order, even bugs. The Python 2→3 transition, Linux syscall stability, and web API evolution are all applied Hyrum’s Law stories. Connects to law-of-leaky-abstractions and law-of-unintended-consequences. See hyrums-law.

Goodhart’s Law — measure-as-target corrupts the measure

“When a measure becomes a target, it ceases to be a good measure.” Originally from Charles Goodhart (1975, monetary policy). The software-engineering version bites in every metrics-driven org: once you grade on lines of code, tickets closed, unit test count, or code review turnaround, the measured variable decouples from the thing you actually wanted. Connects directly to behavioral-psychology (reward shaping), goal-gradient-effect (metrics trigger gaming near thresholds), and principal-agent-problem (agents optimise measured outcomes, not principal’s true interest). The antidote is usually Gilb’s Law balanced with Goodhart: measure, but don’t target — or measure multiple independent signals so gaming one doesn’t win. See goodharts-law.

Hofstadter’s Law — self-referential estimation error

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.” The punchline is the self-reference: awareness of the bias doesn’t eliminate it. Connects to the planning fallacy (Kahneman, who documents it in Thinking, Fast and Slow), to Parkinson’s Law (the opposite force: work expands to fill available time), and to the Ninety-Ninety Rule (the last 10% takes as long as the first 90%). See hofstadters-law.

Cross-Thread Connections

The collection is a decisions/engineering cluster that threads through almost every existing area of the wiki:

Behavioural economics & psychology. dunning-kruger-effect and confirmation-bias are the Kahneman/Thaler biases restated in engineering dress. sunk-cost-fallacy already lives in the wiki and sits under both clusters. hanlons-razor is a heuristic for the fundamental-attribution-error (to be filled in later).

Decision tools. first-principles-thinking, inversion, occams-razor, pareto-principle are all tools in Munger’s latticework. Occam and Pareto are among Munger’s explicit top mental models. Cunningham’s Law is a surprisingly potent knowledge-discovery hack — close cousin to Naval’s “tweet is better than an essay when you want feedback.”

Agency & productivity. conways-law explains why founder-mode companies build more integrated systems (flat comms → unified design). brooks-law is high-agency’s constraint: throwing bodies at a late project doesn’t work; only clear thinking and focused execution does. parkinsons-law + hofstadters-law together explain why good constraints matter: with too little time, Hofstadter wins; with too much, Parkinson wins. pareto-principle is Naval’s implicit rule — find the 20% of work that produces 80% of outcomes.

Game theory & incentives. goodharts-law is the principal-agent-problem restated in the language of metrics. metcalfes-law is the formal underpinning of network-effect businesses and connects to Naval’s leverage thread (code and media at zero marginal cost, scaling as n² by participation). tragedy-of-the-commons (not in this source, but implied by Bus Factor and Technical Debt) is the teams analogue of prisoners-dilemma.

Knowledge evolution. lindy-effect is a Bayesian prior on survival: the longer something has existed, the longer its expected remaining life. Connects naturally to fallibilism (durable ideas are the ones that have survived the most criticism) and to Taleb (Lindy is Taleb’s framing, though the name dates to 1964). Opposes the hype-cycle-amaras-law bias toward short-run overestimation.

Philosophy & reasoning. occams-razor is a first-principles-thinking companion: once you’ve reasoned from basics, prefer the simplest explanation that accounts for the facts. hanlons-razor reduces paranoid reasoning (mainstream wysiati applied to motive) by offering a more economical alternative explanation.

Quality / evolution. broken-windows-theory (from urban policing, imported to software) generalises to any environment where signalling matters — broken code legitimises broken code. lehmans-laws are the “natural history” of software evolution — change is mandatory, complexity grows unless actively managed.

Caveats

  1. Laws are aphorisms, not theorems. With the exception of cap-theorem (proven by Gilbert & Lynch 2002) and amdahls-law / gustafsons-law (straightforward algebra), none of these are formal results. They are strong priors, not proofs. Treating them as literal laws is a misreading.
  2. Many are self-cancelling in pairs. Parkinson vs. Hofstadter; DRY vs. Premature Abstraction; YAGNI vs. Gall’s Law (start simple vs. don’t underbuild). The collection’s usefulness is not a rulebook — it’s a set of forces to balance.
  3. Most were named after their second user. Stigler’s law of eponymy: Conway’s Law is frequently credited to Fred Brooks, Hyrum’s Law was obvious to many before Wright formalised it, and “Murphy” was probably George Nichols. The credits on the site are conventional, not historical.
  4. The source file has no body text beyond headlines. The wiki pages draw additional context from general engineering knowledge.

Raw File

raw/Laws of Software Engineering.md — ~300 lines, most of which are inline SVG illustrations from the site.

Graph View

Backlinks