I’ve been in the software industry for the past 20+ years, and in that time, I’ve encountered many software laws without fully realizing their scope. These include things like “Adding people to a late project makes it later,” “A complex system that works evolved from a simple system that worked,” and “Code that isn’t tested doesn’t work.” These are no random pieces of wisdom. They are simply patterns that evolved out of many years of software development.
Since these lessons are scattered throughout old books, blog posts, and tribal knowledge, the idea to gather them in one place arose. They range from lessons in the 1960s to those in the past 10 years. Each one is talking about the forces you’ve already seen firsthand: why a rewrite failed, why the estimate was wrong, why “tweaking this one thing” broke three others.
None of them is actually a law in the legal or scientific sense, although a few do have backing in research. One way of understanding them would be as “rules of thumb,” where the tip works well in most instances but occasionally breaks when the situation changes.
I wrote this more as a way to stop reinventing the same lessons. It seems that everyone has to learn these things the hard way. This site (and the book) compiles 63+ laws and principles, with explanations of where they came from and why they’re still relevant today.
Regardless of whether you are a developer, technical lead, or engineering manager, these patterns will help you in decision-making and prevent you from making the same mistake twice.
The Big Picture
A bird’s eye view of all the laws and principles, organized by category:
Click to download the full PDF versionHow to Use
Here is a short guide on how this book can help you:
- Project timeline planning? Here, Hofstadter’s Law reminds us that it will probably take longer than we planned. The Ninety-Ninety Rule cautions us that the final 10% will take half the time. And Parkinson’s Law tells us why: work expands to fill the time allotted to it.
- Team scaling? Brooks’s Law explains why adding people to a late project makes it later. The Ringelmann Effect illustrates how productivity per person decreases as team size increases. Conway’s Law explains why your organization’s structure is reflected in your code.
- Architectural design? Begin with Gall’s Law: complex systems that work are derived from simple systems. YAGNI helps you not build what you don’t need. Premature Optimization reminds you to measure before you optimize.
- Code quality? The Boy Scout Rule says to leave code better than you found it. The DRY Principle reduces duplication. Technical Debt is how shortcuts today cost you tomorrow.
- API design? Hyrum’s Law reminds us that users will depend on all observable behavior. Postel’s Law advises you to be liberal in what you accept and conservative in what you send. The Law of Leaky Abstractions describes why abstractions work hard to conceal complexity.
- Complexity management? Complexity can never be eliminated, according to Tesler’s Law. Simpler is always better, according to the KISS Principle. Occam’s Razor suggests the explanation requiring the fewest assumptions.
You can read it from front to back, or use it as a reference when you hit a specific problem.
Categories
The laws are organized into seven groups based on how problems actually show up in your work:
- Architecture. System design, system structure, and technical decisions. These laws explain why designs succeed or fail and when to choose simplicity over flexibility.
- Teams. Human dynamics of software development. Writing software is a team sport, and these laws explain why communications break down and why the structure of your organization conspires against you to mold your code.
- Planning. Estimation and scheduling. Why projects rarely go according to plan.
- Quality. Better code, more reliable systems.
- Scale. What happens when systems and teams grow. Small solutions break at scale.
- Design. The interfaces, APIs, and system interactions.
- Decisions. Mental models and cognitive traps that influence engineering decisions.
Further Reading
Deep dives into the laws and patterns covered in this collection:
- The 20 Software Engineering Laws Twenty fundamental principles rooted in human nature that explain why projects fail and systems decay
- Why You Cannot Deliver Fast With the Same Quality The Project Management Triangle and why software projects are always late
- The 12 Mental Models and Biases for Engineers Second-order thinking, first principles, and cognitive biases that affect decisions
- Your Architecture is as Complex as Your Organization Conway's Law in practice, and why small teams win
- All Estimations Are Wrong, But None Are Useful Hofstadter's Law, Planning Fallacy, and dealing with uncertainty
- How to Fight Impostor Syndrome The Dunning-Kruger Effect and restoring your self-esteem as an engineer
- Why You Should Build a Modular Monolith First Gall's Law applied: start simple, evolve as needed
- How to Deal with Technical Debt Measuring, managing, and preventing the debt that slows you down
Contact
Have feedback, questions, or ideas for new laws? I’d love to hear from you.