A site collecting the canonical laws of software engineering surfaced on Hacker News recently with 446 points and a lively comment thread. The usual suspects are there: Brooks’s Law, Conway’s Law, Postel’s Law, Hofstadter’s Law, Hyrum’s Law. Worth thinking about not just what these laws say, but what kind of claims they are making and whether the evidence supports them.
Software engineering has a peculiar relationship with its own aphorisms. Fields like physics have laws that carry mathematical weight and predictive power. Fields like economics have laws that are really tendencies with significant exceptions. Software engineering laws tend to fall into an even murkier category: observations that were sharp and specific when first stated, that got repeated and compressed over decades, and that now exist somewhere between genuine insight and comfortable mythology.
Brooks’s Law and the Limits of Compression
Fred Brooks stated his famous law in The Mythical Man-Month in 1975: “Adding manpower to a late software project makes it later.” This one has real empirical grounding. Brooks was drawing from his experience managing OS/360 at IBM, and the mechanism he described is specific and traceable: new team members require onboarding time from existing members, communication overhead scales as O(n²) with team size, and tasks that cannot be parallelized remain on the critical path regardless of how many people you add.
But the compressed version strips out those mechanisms. What gets repeated is the headline, not the underlying model. Brooks actually wrote that there are tasks that can be parallelized, and that adding people to projects that are early or well-partitioned can work. The law as commonly cited is a special case presented as a universal. The nuance lives in the book; the aphorism lives in Slack messages.
This compression problem affects nearly every law on the list. A sharp observation about a specific context, stripped of its qualifications, repeated until it sounds like gravity.
Conway’s Law Has Surprising Empirical Support
Conway’s Law comes from Melvin Conway’s 1967 paper: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” This one has held up better than most, and in ways that are quantifiable.
A 2008 study by Alan MacCormack, John Rusnak, and Carliss Baldwin at Harvard Business School compared the modularity of open-source products against their corporate equivalents building similar software. They found that loosely-coupled organizations produced more modular software. The “Inverse Conway Maneuver,” popularized in the microservices literature, explicitly tries to engineer org structure to produce desired architecture rather than the other way around. Teams at Amazon famously use the two-pizza rule partly as an architectural tool, not just a management preference.
The law predicts something falsifiable and researchers have found evidence for it. That puts it in a stronger epistemic category than most of the list.
Postel’s Law Under Revision
Jon Postel’s Robustness Principle, first formalized in RFC 793 in 1980, reads: “Be conservative in what you do, be liberal in what you accept from others.” For decades this read as unambiguous wisdom. Build tolerant parsers. Don’t break on minor malformations. Prioritize interoperability.
The internet security community has spent the last fifteen years documenting the ways this principle has caused serious harm. Martin Thomson’s 2015 IETF draft titled “The Harmful Consequences of the Robustness Principle” laid out the argument systematically: liberal acceptance prevents protocol evolution, because any behavior that gets accepted gets depended upon. It creates ambiguity that attackers exploit. HTML parsing in browsers is the canonical example, where decades of “be liberal” produced a parser that behaves differently across implementations in ways that have enabled XSS attacks, click-jacking, and misdirection.
Postel’s Law is not wrong in every context. Accepting minor formatting variations in user-facing text fields is fine. But applying it wholesale to security-sensitive protocol parsing is demonstrably harmful, and the law as usually stated carries no such distinction.
Hyrum’s Law Is the Best-Grounded Modern Addition
Hyrum’s Law, formulated by Hyrum Wright at Google, is the most precisely stated of the newer additions: “With a sufficient number of users of an API, it does not matter what you contract promises — all observable behaviors will be depended upon.”
This one is grounded in the specific experience of maintaining large-scale systems with many consumers. Google’s internal codebase has hundreds of millions of lines of code and thousands of teams. Wright and colleagues documented this empirically by studying what broke when they tried to make changes that were technically within their API contract. The answer was: a lot.
A concrete example: if your API sorts results in a particular order as a side effect of your implementation, and that order is not part of your contract, but you have ten thousand callers, some of those callers will have been written assuming that order. Changing to a hash map internally, which happens to change output order, will break them. The contract said nothing about ordering. Hyrum’s Law predicts this outcome regardless.
This has real design implications. It suggests that large public APIs should be deliberately narrow and that interface documentation should describe not just what is guaranteed but what is explicitly not guaranteed, because the gap between those two sets is where dependence accumulates. Go’s standard library uses this reasoning explicitly; the language spec distinguishes between specified behavior and implementation behavior more carefully than most.
The law also has a corollary that rarely gets discussed: it implies that perfectly correct automated refactoring is impossible at sufficient scale. Even a refactoring that preserves documented behavior will break undocumented behavior that someone depends upon. This is one reason Google developed tools like Rosie for large-scale automated code changes, with mandatory testing pipelines to catch Hyrum-style regressions.
Hofstadter’s Law and the Limits of Self-Reference
Hofstadter’s Law from Gödel, Escher, Bach (1979) reads: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” This is clever but the cleverness obscures its emptiness as a predictive tool. It tells you that estimates will be wrong but gives you no mechanism for making them better. It cannot be falsified because it accommodates any outcome.
This is a pattern in several of these laws. They describe a class of failure modes accurately enough to be recognizable, but they do not generate predictions you can act on. Knowing that estimates are systematically optimistic is useful context. Evidence-based scheduling, reference class forecasting, and the planning fallacy literature from behavioral economics give you actual tools. Hofstadter gives you a self-aware shrug.
Lehman’s Laws Are the Most Overlooked
Manny Lehman and László Bélády developed eight Laws of Software Evolution between 1974 and 1996, based on longitudinal studies of IBM OS/360. These are probably the most empirically grounded laws on any such list, and the least commonly cited in day-to-day engineering discourse.
The most important for practicing engineers is the Law of Continuing Change: “An E-type program [one that models real-world activity] must be continually adapted or it becomes progressively less satisfactory.” This sounds obvious until you consider its implication: software that is not actively maintained is decaying, not stable. A system that has not changed in two years has not been preserved; it has been abandoned to accumulating mismatch with the environment it runs in, the requirements it serves, and the dependencies it relies on.
Lehman’s Second Law, Increasing Complexity, states that as a program evolves, its complexity increases unless work is done to reduce it. This gives a precise framing for technical debt: not as a metaphorical financial obligation, but as entropy that requires active expenditure to reverse. The laws together describe a kind of thermodynamics of software systems, and they came from actual empirical observation of a large production codebase over years.
What the Collection Reveals
Looking at these laws as a corpus, the epistemological quality varies enormously. Some, like Conway’s and Lehman’s, have real empirical support and falsifiable predictions. Some, like Hyrum’s, are precise observations about specific mechanisms with documented examples. Some, like Hofstadter’s, are witty but produce no actionable predictions. And some, like Postel’s, were reasonable observations that hardened into dogma and then turned out to have significant failure modes.
The value of collecting them is not that they are all correct or that you should apply them uncritically. It is that each one names something that practitioners have encountered repeatedly enough to bother naming. The naming matters because it gives teams shared vocabulary for a class of problems. “This is a Conway’s Law problem” is faster than re-explaining organizational communication theory from scratch every time.
But vocabulary is not the same as understanding, and pattern-matching to a named law is not the same as diagnosing what is actually happening. The laws are entry points, not conclusions.