Laws of Software Engineering

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.

Praise for the book

“Laws of Software Engineering is an invaluable book that should be on the shelf of any technical leader, architect, or aspiring senior developer.”

— Adam Tornhill, Author of Your Code as a Crime Scene, CTO at CodeScene

“A delightfully compact book infused with hard-earned lessons of wisdom. You can either spend decades discovering these laws through the scars of experience, or allow Milan to unlock their secrets in a single weekend.”

— Maarten Dalmijn, Author of Driving Value with Sprint Goals