Laws of Software Engineering: A Reference Worth Bookmarking

The 56 entries are organised into eight categories:

• Architecture - principles that shape how systems are structured (Conway's Law, Hyrum's Law, the Single Responsibility Principle, etc).
• Teams - laws about how humans collaborate on software (Brooks's Law - adding people to a late project makes it later - is the canonical example).
• Planning - cost, scope and estimation principles (Hofstadter's Law - it always takes longer than you expect, even when you account for Hofstadter's Law - lives here).
• Quality - testing, robustness and error-handling principles.
• Scale - what changes as systems grow.
• Design - higher-level design principles (YAGNI: You Aren't Gonna Need It; KISS: Keep It Simple; DRY: Don't Repeat Yourself).
• Decisions - heuristics for engineering choice-making.
• CAP - distributed-systems specific (the CAP Theorem itself plus related principles).

Each entry includes a one-line statement, a longer explanation, concrete examples of where it applies, and tags for the audience level (Junior, Mid-Level, Senior).

If you've never gone down this rabbit hole, five entries pay for the visit on their own:

• Conway's Law - organisations design systems that mirror their own communication structures. Most useful when you're wondering why a system has a weirdly-shaped boundary between modules: look at the team org chart and you'll often see the same boundary there.
• Hyrum's Law - with a sufficient number of API users, all observable behaviours of your system will be depended on by somebody. This is why you can't trust 'undocumented behaviour' to stay changeable in a public API. People will find it and depend on it.
• Brooks's Law - adding people to a late software project makes it later. The onboarding cost + new-coordination overhead exceeds the throughput gain from the additional hands.
• YAGNI (You Aren't Gonna Need It) - don't add functionality based on what you imagine you'll need. Add it when you actually need it. Saves vast amounts of code that exists only to support edge cases that never materialise.
• CAP Theorem - distributed systems can guarantee at most two of consistency, availability, and partition tolerance. The choice you make defines what your system can and can't promise.

You could read 56 of these in a single book (and books exist - the site links one). But the value of a reference catalogue is different from the value of cover-to-cover reading.

When you hit a specific situation - a feature shipped but ten customers are now relying on a side-effect you didn't document; a small change touches three teams and slows to a crawl; an estimate blows past its deadline for the third time - what you actually want is the one-line distillation that names what's happening, so you can talk about it without having to explain the whole concept from scratch.

The Laws of Software Engineering site is set up exactly for that: search by name, filter by category, copy the canonical statement into your design doc or post-mortem. The audience-level filtering also makes it useful for handing to a junior engineer who needs the vocabulary without the full architectural-history context.

Yes. The signal-to-noise is high, the curation is opinionated in the right ways, and the format makes it easy to jump in and out. I've found myself linking to specific entries in PR reviews and design docs since I started using it, which is the best test of a reference site - does it actually become part of the working vocabulary, or does it gather dust in your bookmarks tab.

Newsletter + poster + book are also offered if you want to absorb the catalogue more deeply, though the website itself is enough for most working uses.