Laws of Software Engineering: A guide to the patterns that shape software systems, teams, and decisions

How did I write this book? For more than 20 years in the industry, when I noticed some rules, I wrote them down. Much later, I found out that other people had come to similar conclusions. Namely, Gall's Law came from a failed rewrite. Brooks's Law from a team that doubled in size and shipped more slowly. Goodhart's Law from a quarter where we hit every metric and built nothing useful. The document kept growing.

Even though others learned this in a similar way to how I did, this way of learning is very expensive, because you learn it by making mistakes. The best way to learn something is from other people's mistakes.

Also, when I researched these rules and laws, I found them scattered everywhere: old academic papers, random blog posts, hallway conversations. What was confusing was that some of them contradict each other. And knowing which one applies to your situation right now is often what separates great engineers from everyone else.

The book presents each law in a separate chapter. What it is, where it came from, some real-world experiences, how to deal with it, and how these laws connect to each other. It's a reference book. The one you leave on your desk, not the kind you read once and put aside.