56 Laws of Software Engineering
56 Laws of Software Engineering
Discovered a comprehensive curated collection of 56 fundamental laws of software engineering — spanning design, teams, estimation, quality, systems, and cognitive biases.
Standout Laws
Conway’s Law — Organizations design systems that mirror their own communication structure. This isn’t just an observation; it’s a tool. Want a different architecture? Restructure the teams first.
Hyrum’s Law — With enough API users, all observable behaviors will be depended on. Even bugs become features once widely adopted. This is why changing public APIs is so dangerous.
Tesler’s Law (Conservation of Complexity) — Complexity can only be shifted, not eliminated. Every “simple” user interface hides complexity somewhere — either in the code, the configuration, or the user’s mental model.
Gall’s Law — Complex systems that work evolved from simple systems that worked. You can’t build a complex system from scratch and expect it to work. Start simple, then evolve.
Goodhart’s Law — When a measure becomes a target, it ceases to be a good measure. Code coverage, lines of code, velocity — all gamed once they’re goals.
Cunningham’s Law — The best way to get the correct answer is to post the wrong answer. This explains why Stack Overflow works and why rubber-duck debugging is effective.
Why This Matters
These aren’t just aphorisms — they’re battle-tested principles that explain why software projects succeed or fail. The site organizes all 56 into clear categories with concise explanations.
Lesson learned: Software engineering has a body of accumulated wisdom codified as “laws.” Knowing them helps you recognize patterns in your own projects and avoid repeating well-documented mistakes.