The site Laws of Software Engineering went up the Hacker News front page recently and pulled nearly 450 points, which tells you something about how much developers enjoy cataloguing their received wisdom. The comments, predictably, split between people citing the laws as settled truth and people pointing out that some of them are barely more than aphorisms with a person’s name attached.
That tension is worth exploring. These “laws” occupy very different epistemic territory from each other. Some have been empirically tested and held up. Some are definitionally true in a way that makes them unfalsifiable. Some made sense in 1975 and have been eroded by changes in tooling, hardware, and team structure. Treating them as a uniform canon is how you end up quoting Brooks’s Law to justify a headcount freeze on a project that bears no resemblance to OS/360.
The Ones That Are Actually Verified
Conway’s Law, stated by Melvin Conway in his 1968 Datamation paper, says that organizations designing systems produce architectures that mirror their communication structures. This one has been studied seriously. A 2012 paper by MacCormack, Baldwin, and Rusnak, “Exploring the Duality between Product and Organizational Architectures,” compared the module coupling of code produced by loosely coupled open-source teams versus tightly coupled commercial teams and found measurable structural differences consistent with the law. Microsoft Research has run similar analyses on internal codebases. Conway’s Law is not just plausible; it has been looked at with actual data and has not collapsed.
The practical implication is significant. If you want a loosely coupled microservices architecture, you need loosely coupled teams. Trying to impose the architecture without restructuring communication tends to produce a distributed monolith, because the humans coordinating on the seams will pull the abstractions back toward their organizational boundaries. This is why the Inverse Conway Maneuver, deliberately restructuring teams to match the target architecture, became a real technique in large-scale systems design.
Hyrum’s Law, articulated by Hyrum Wright at Google and discussed at length in Software Engineering at Google, is newer and more narrowly scoped: with enough users of an API, every observable behavior will be depended upon by someone, regardless of what the documented contract says. This one is definitionally hard to refute once you have accepted what it means by “sufficient number of users,” but it is not empty. The implication is concrete: at scale, there is no such thing as an internal implementation detail if it is observable. Latency profiles, error message wording, ordering of results that the spec treats as undefined, behavior on malformed input that technically violates the contract, all of it gets depended upon. Anyone who has shipped a library used by more than a few hundred projects has encountered this.
I ran into a version of it while working on a Discord bot framework. I changed how the bot serialized a timestamp in an internal event payload, something no documented API surface touched, and broke two downstream scripts someone had written to parse the bot’s log output. Hyrum’s Law at a very small scale, but the structure is identical.
The Useful Heuristics Dressed as Laws
Brooks’s Law, from Fred Brooks’s 1975 book The Mythical Man-Month, states that adding people to a late software project makes it later. The mechanism Brooks proposed is that onboarding cost and communication overhead grow roughly with the square of team members, so the short-term drag of bringing someone new up to speed exceeds the short-term gain in output.
This is a useful heuristic with real explanatory power for a certain class of projects, but calling it a law overstates the universality. It applies most strongly to projects with high interdependency between tasks and significant onboarding complexity. A parallelizable project with clear module boundaries and good documentation can absorb new contributors without the classic Brooks penalty. Open-source projects add contributors mid-flight all the time. The law is better understood as a warning about a specific failure mode than as a universal constraint.
Goodhart’s Law did not originate in software, coming instead from economist Charles Goodhart’s 1975 observation about monetary policy targets, but it applies with brutal precision to engineering metrics. The standard formulation is: when a measure becomes a target, it ceases to be a good measure. In software this surfaces constantly. Story points as velocity metrics get gamed until the points measure nothing. Code coverage targets produce tests that execute code without asserting anything meaningful. Deployment frequency as a DORA metric produces tiny no-op deploys. The measure starts as a proxy for the thing you care about and ends as a substitute for it.
The Tautologies
Hofstadter’s Law states that a task always takes longer than expected, even when you account for Hofstadter’s Law. The self-referential structure is charming but it means the law cannot be violated, which means it is not predicting anything. It is a joke about the intractability of estimation dressed in the clothes of a law. That does not make it useless as a reminder to pad your estimates, but you should not confuse it with something that tells you why estimation is hard or what to do about it.
The Era-Specific Ones
Wirth’s Law, software gets slower faster than hardware gets faster, was coined by Niklaus Wirth in a 1995 paper titled “A Plea for Lean Software.” It resonated in the 1990s when managed runtimes, garbage collectors, and increasingly abstracted frameworks were piling overhead onto hardware that was doubling in speed every eighteen months. In 2026, the hardware scaling story is more complicated. Single-core clock speeds have plateaued. DRAM latency has barely moved in a decade. The places where software genuinely got “slower” were often justified by developer productivity, security, or correctness tradeoffs that the hardware performance gains made affordable. The places where it was unjustified bloat are real but harder to attribute to a clean law.
Postel’s Law, “be conservative in what you send, be liberal in what you accept,” shaped TCP/IP and an enormous amount of internet protocol design. It has also been seriously criticized. Mark Nottingham and others have argued that liberal acceptance of malformed input is precisely what makes protocols accumulate technical debt, security vulnerabilities, and cross-implementation inconsistencies. HTML parsing is a canonical example: browsers’ willingness to accept malformed markup created an ecosystem of pages that only worked in certain parsers, making the ecosystem harder to move. The law may have been right for a bootstrapping phase of the internet and wrong as a permanent posture.
What to Do With All of This
The value of these named laws is not that they are universally true. It is that each one captures a pattern that was observed frequently enough that someone gave it a name, which makes it faster to reason about and communicate. Conway’s Law in a team discussion immediately invokes a whole model of organizational coupling. Goodhart’s Law in a metrics review cuts through a lot of defensive argument.
But the names create a false sense of authority. A law sounds like a law of physics, invariant and deduced from first principles. Most of these are generalizations from limited observation, made in a specific era, about systems that shared certain characteristics. Applying them thoughtfully means asking: does this project share the characteristics that made the pattern hold? Is the mechanism that drives this law present in my situation?
The HN thread has, as it usually does for this kind of compilation, a useful subthread where people dispute which laws belong and which are redundant or overfit. That conversation is arguably more useful than the list itself, because it forces you to articulate why each one holds rather than just accepting it as received wisdom.
The best engineering judgment is not knowing the laws. It is knowing when they apply.