Mike's Notes
Dr Milan Milanovic has written a 300-page book about the laws of software engineering. It looks great. There is also a website, a newsletter and a printable poster. It is a very useful collection of 56 laws for future reference.
Missing Laws
- Glass's Law: For every 25% increase in the complexity of the problem space, there is a 100% (fourfold) increase in the complexity of the solution space.
- Session's Law:
- The Law of Exponential Complexity: As you add more components to a system, the complexity increases exponentially, not linearly.
- Equivalence Relations & Partitioning: Sessions argues that the only way to manage massive IT complexity is through partitioning—breaking a large system into smaller, independent "Snowman" units that do not share state or data directly.
- Mathematical Predictability: He uses these laws to calculate the probability of IT project failure based on the number of interconnected components.
Heuristics
While this name suggests rigid scientific "laws," it is more accurately described as a series of heuristic, or mental shortcuts or empirical observations that help teams understand.
Complex Adaptive System (CAS)
I knew about some of these heuristics and designed Pipi as a CAS to break many of them. π Laws of Software Engineering gives me a clear target to smash.
Website
On the Laws of Software Engineering website, there is a link from each law to a page with sections covering;
- Takeaways
- Overview
- Examples
- Origin
- Further Reading
I copied the 56 laws here from the website, subscribed to the newsletter, and printed off the poster. I must get the book. Very cool.
Thank you, Dr Milan Milanovic. π
From Amazon
"Conway's Law. Brooks's Law. Goodhart's Law. Hyrum's Law. If you've been writing software long enough, you've recognized these rules even before you knew their names. If you had an opportunity to see a failed rewrite, or a time that is getting bigger but slower, you hit into these rules.
These patterns have been showing up in software projects for over fifty years. Experienced engineers know them, but they learned them the hard way. These lessons were never in one place, where you could read them. They lived in academic papers from the 1960s, but also in some blog posts that get shared once and forgotten. I also found them in discussions and code reviews.
This book puts all of them in one place. 63+ laws and principles, each with its own chapter, with forewords by Dr. Rebecca Parsons (CTO Emerita at Thoughtworks) and Addy Osmani (Engineering Director at Google Cloud AI).
Each chapter covers where the law came from, how it actually works, what it looks like in the real world, and how it connects to other laws in the book. That last part matters. Some of these principles reinforce each other, and others directly conflict. The "Related Laws" sections throughout the book show you where those connections are. This is important because in practice, engineering is about tradeoffs, not rules.
The book is organized into seven standalone parts:
- Part I: Architecture & Complexity. 8 laws, including Gall's Law, CAP Theorem, and Hyrum's Law.
- Part II: People, Teams & Organizations. 10 laws, including Conway's Law, Brooks's Law, and the Peter Principle.
- Part III: Time, Estimation & Planning. 6 laws, including Hofstadter's Law and Goodhart's Law.
- Part IV: Quality, Maintenance & Evolution. 10 laws including Technical Debt, Lehman's Laws, and Testing Pyramid.
- Part V: Scale, Performance & Growth. 4 laws, including Amdahl's Law and Metcalfe's Law.
- Part VI: Coding & Design Principles. 6 laws including SOLID, DRY, and YAGNI.
- Part VII: Decision-Making & Biases. 13 laws, including Occam's Razor, Dunning-Kruger Effect, and Pareto Principle.
Many chapters also cover companion laws within them: George Box's Law, The Spotify Model, Two Pizza Rule, The Dead Sea Effect, The Cobra Effect, Impostor Syndrome, and more. There's more in here than the table of contents suggests.
You don't need to read it front to back. Each chapter stands alone. Building a distributed system? Start with Part I. Team problems? Part II. Estimation problems? Part III. Codebase issues? Part IV. Or just start at page one. That works too.
Half the book covers people, organizations, and how we make decisions, not just technology. Remember that this is not a coding tutorial and it won't teach you a programming language or framework.
If you've been in the industry for a while, you'll probably recognize some of these laws. Here you will learn about other laws and how they are connected and affect each other. You will also learn to understand it in depth, so it becomes useful for your current or next projects. And if you're earlier in your career, this book gives you the vocabulary your senior colleagues already have." - Amazon
Resources
- https://lawsofsoftwareengineering.com/
- https://lawsofsoftwareengineering.com/book/
- https://newsletter.techworld-with-milan.com/
- https://newsletter.techworld-with-milan.com/p/the-20-software-engineering-laws
References
- Laws of Software Engineering by Dr Milan Milanovic (2026).
Repository
- Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
- Home > Ajabbi Research > Library > Subscriptions > Techworld with Milan
- Home > Handbook >
Last Updated
27/04/2026
Laws of Software Engineering
I’m a software engineer and CTO with over 20 years of experience, from startups to large enterprises, including big tech as a contractor. I hold a Ph.D. in Computer Science, have authored over 20 scientific publications with 440+ citations, and am recognized as a Microsoft MVP for Developer Technologies.
With each new role, from developer to architect to CTO, I encountered the same patterns. The same struggles. The same failures. The same hard-won insights that engineers keep rediscovering, often at great cost.
I started collecting these laws and principles for myself, then for my teams. When I started my newsletter, I shared them with the world. Today, my writing on software, architecture, and leadership reaches over 400,000 engineers.
This book represents everything I wish I’d had when I started. I hope it spares you some of the pain I went through.
A collection of principles and patterns that shape software systems, teams, and decisions.
Part I: Architecture & Complexity (Architecture)
1. Gall's Law
A complex system that works is invariably found to have evolved from a simple system that worked.
2. The Law of Leaky Abstractions
All non-trivial abstractions, to some degree, are leaky.
+ George Box's Law
3. Tesler's Law (Conservation of Complexity)
Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.
4. CAP Theorem
A distributed system can guarantee only two of: consistency, availability, and partition tolerance.
5. Hyrum's Law
With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody.
6. Second-System Effect
Small, successful systems tend to be followed by overengineered, bloated replacements.
7. Fallacies of Distributed Computing
A set of eight false assumptions that new distributed system designers often make.
8. Law of Unintended Consequences
Whenever you change a complex system, expect surprise.
9. Zawinski's Law
Every program attempts to expand until it can read mail.
Part II: People, Teams & Organizations (Teams)
10. Conway's Law
Organizations design systems that mirror their own communication structure.
+ The Spotify Model
11. Brooks's Law
Adding manpower to a late software project makes it later.
+ Little's Law
12. Dunbar's Number
There is a cognitive limit of about 150 stable relationships one person can maintain.
13. The Ringelmann Effect
Individual productivity decreases as group size increases.
+ The Two-Pizza Rule
14. Price's Law
The square root of the total number of participants does 50% of the work.
15. Putt's Law
Those who understand technology don't manage it, and those who manage it don't understand it.
16. Peter Principle
In a hierarchy, every employee tends to rise to their level of incompetence.
17. Bus Factor
The minimum number of team members whose loss would put the project in serious trouble.
+ The Dead Sea Effect
18. Dilbert Principle
Companies tend to promote incompetent employees to management to limit the damage they can do.
Part III: Time, Estimation & Planning (Planning)
19. Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
20. Parkinson's Law
Work expands to fill the time available for its completion.
21. The Ninety-Ninety Rule
The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%.
22. Goodhart's Law
When a measure becomes a target, it ceases to be a good measure.
+ The Cobra Effect
23. Gilb's Law
Anything you need to quantify can be measured in some way better than not measuring it.
24. Premature Optimization (Knuth's Optimization Principle)
Premature optimization is the root of all evil.
Part IV: Quality, Maintenance & Evolution (Quality)
25. Murphy's Law / Sod's Law
Anything that can go wrong will go wrong.
26. Postel's Law
Be conservative in what you do, be liberal in what you accept from others.
27. Broken Windows Theory
Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired.
28. The Boy Scout Rule
Leave the code better than you found it.
29. Technical Debt
Technical Debt is everything that slows us down when developing software.
30. Linus's Law
Given enough eyeballs, all bugs are shallow.
31. Kernighan's Law
Debugging is twice as hard as writing the code in the first place.
32. Testing Pyramid
A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests.
+ The BeyoncΓ© Rule
33. Pesticide Paradox
Repeatedly running the same tests becomes less effective over time.
34. Lehman's Laws of Software Evolution
Software that reflects the real world must evolve, and that evolution has predictable limits.
35. Sturgeon's Law
90% of everything is crap.
Part V: Scale, Performance & Growth (Scale)
36. Amdahl's Law
The speedup from parallelization is limited by the fraction of work that cannot be parallelized.
37. Gustafson's Law
It is possible to achieve significant speedup in parallel processing by increasing the problem size.
38. Metcalfe's Law
The value of a network is proportional to the square of the number of users.
+ Sarnoff's & Reed's Laws
Part VI: Coding & Design Principles (Design)
39. DRY (Don't Repeat Yourself)
Every piece of knowledge must have a single, unambiguous, authoritative representation.
40. KISS (Keep It Simple, Stupid)
Designs and systems should be as simple as possible.
41. YAGNI (You Aren't Gonna Need It)
Don't add functionality until it is necessary.
42. SOLID Principles
Five main guidelines that enhance software design, making code more maintainable and scalable.
43. Law of Demeter
An object should only interact with its immediate friends, not strangers.
44. Principle of Least Astonishment
Software and interfaces should behave in a way that least surprises users and other developers.
Part VII: Decision-Making & Biases (Decisions)
45. Dunning-Kruger Effect
The less you know about something, the more confident you tend to be.
+ Impostor Syndrome
46. Hanlon's Razor
Never attribute to malice that which is adequately explained by stupidity or carelessness.
47. Occam's Razor
The simplest explanation is often the most accurate one.
48. Sunk Cost Fallacy
Sticking with a choice because you've invested time or energy in it, even when walking away helps you.
49. The Map Is Not the Territory
Our representations of reality are not the same as reality itself.
50. Confirmation Bias
A tendency to favor information that supports our existing beliefs or ideas.
51. The Hype Cycle & Amara's Law
We tend to overestimate the effect of a technology in the short run and underestimate the impact in the long run.
52. The Lindy Effect
The longer something has been in use, the more likely it is to continue being used.
53. First Principles Thinking
Breaking a complex problem into its most basic blocks and then building up from there.
54. Inversion
Solving a problem by considering the opposite outcome and working backward from it.
55. Pareto Principle (80/20 Rule)
80% of the problems result from 20% of the causes.
56. Cunningham's Law
The best way to get the correct answer on the Internet is not to ask a question, it's to post the wrong answer.
