We’ve all been there. The project, let’s call it “Phoenix,” was six weeks behind schedule. The Gantt chart was a sea of red, morale was cratering, and the daily stand-up felt more like a daily confession. The executive response? The classic, knee-jerk solution: “Let’s add more engineers. We’ll throw bodies at the problem and catch up.”
We added four new developers to the team of six. And a funny thing happened. Our velocity—the rate at which we shipped working software—didn’t just fail to increase. It went down. Communication tangled, onboarding the new folks consumed our best engineers’ time, and the complexity of the codebase suddenly felt ten times heavier. We were living out Brooks’s Law in real-time, and it was painful.
This post is for engineering managers, tech leads, and senior individual contributors who have felt that pain. It’s for anyone who has realized that building software is governed by a set of unwritten, often counterintuitive, laws. Understanding these principles won’t give you a magic formula for success, but it will provide a powerful mental toolkit to diagnose what’s going wrong and make better decisions under pressure.
⚠️ For each section, I’ve linked more detailed posts about each of them, which go deeper into the topic.
General Principles
- Pareto Principle: For many events, roughly 80% of the effects come from 20% of the causes. This principle is a fundamental law of distribution that appears everywhere in software development. It dictates that value, problems, and effort are rarely distributed evenly. Instead, a small, critical minority of inputs is responsible for the overwhelming majority of outputs.
- Ockham’s Razor: The simplest solution is most likely the right one. In software, this translates to a simple, powerful directive: when faced with multiple solutions that achieve the same outcome, the one with the fewest assumptions, dependencies, and moving parts is almost always the correct choice.
👬 Team & Project Management
⚠️ Click here for the full article
- Brooks’ Law: Adding human resources to a late software project makes it later.
- Price’s Law: In any group, 50% of the work is done by the square root number of people.
- Ringelmann Effect: Individual members of a group become increasingly less productive as the size of their group increases.
- Cagan’s Law: We need teams of missionaries, not teams of mercenaries.
- Peter Principle: People in a hierarchy tend to rise to a level of respective incompetence.
⏱︎ Time & Estimation
⚠️ Click here for the full article
- Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
- Parkinson’s Law: Work expands so as to fill the time available for its completion.
- Ninety-Ninety Rule: The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent accounts for the other 90 percent.
- Cohn’s Laws of Estimates: Estimates are Waste, Non-Transferable, Wrong, Temporary, and Necessary.
👩💻 Coding & Development
⚠️ Click here for the full article
- Knuth’s Optimization Principle: Premature optimization is the root of all evil.
- Kernighan’s Law: Everyone knows that debugging is twice as hard as writing a program in the first place.
- Tesler’s Law: Every application has an inherent amount of complexity that cannot be removed or hidden.
- Spolsky’s Law of Leaky Abstractions: All non-trivial abstractions, to some degree, are leaky.
🏛️ System Architecture
⚠️ Click here for the full article
- Conway’s Law: Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
- Gall’s Law: A complex system that works has evolved from a simple system that worked.
- Hyrum’s Law: With a sufficient number of users of an API, all observable behaviors will be depended on by somebody.
- Postel’s Law: Be conservative in what you do, be liberal in what you accept from others.
🧔 Human Factors
⚠️ Click here for the full article
- Cunningham’s Law: The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.
- Dunning-Kruger Effect: Low performers are unable to recognize the skill and competence levels of other people.
- Yerkes-Dodson Law: Elevated arousal levels can improve performance up to a certain point.
👩🔬 Quality & Testing
⚠️ Click here for the full article
- Linus’s Law: Given enough eyeballs, all bugs are shallow.
- Pesticide Paradox: If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs.
- Sturgeon’s Law: 90% of everything is crap.
🔐 Risk & Security
⚠️ Click here for the full article
- Murphy’s Law: If there is a wrong way to do something, then someone will do it.
- Kerckhoffs’ Principle: A system should be secure even if everything about the system, except the key, is public knowledge.
🐎 Performance & Scalability
⚠️ Click here for the full article
- Amdahl’s Law: The speedup gained from running a program on a parallel computer is greatly limited by the fraction that can’t be parallelized.
- Moore’s Law: The complexity for minimum component costs has increased at a rate of roughly a factor of two per year.
- Wirth’s Law: Software gets slower faster than hardware gets faster.
📊 Metrics & Monitoring
⚠️ Click here for the full article
- Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.
- Gilb’s Law: Anything you need to quantify can be measured in some way that is superior to not measuring it at all.
🎨 Design & UX
⚠️ Click here for the full article
- Jakob’s Law: Users spend most of their time on other sites, so users prefer your site to work the same way as all the other sites they already know.
- Fitts’ Law: The time to acquire a target is a function of the distance to and the size of the target.
🚧 Product Development
⚠️ Click here for the full article
- Zawinski’s Law: Every program attempts to expand until it can read mail.
- Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.
Putting It All Together
These 56 laws represent decades of collective wisdom from software engineers who’ve learned from both spectacular failures and remarkable successes. They’re not rigid rules, but flexible guidelines that help you make better decisions when facing uncertainty.
The key insight? Software development is fundamentally a human activity. Technology changes rapidly, but human nature remains constant. Laws about communication, psychology, and organizational behavior often matter more than laws about algorithms or architecture.
Start by mastering a few laws that resonate with your current challenges. As you gain experience, you’ll discover which principles apply to your specific context and which situations require breaking the rules entirely.
Remember: these laws describe patterns, not prescriptions. Use them as navigation tools, not religious doctrine. The best software engineers understand the rules so well they know exactly when and how to break them.