Laws of Software Engineering
A collection of principles and patterns that shape software systems, teams, and decisions.
1.1k points on Hacker News
Level
Category
Teams
Conway's Law
Organizations design systems that mirror their own communication structure.
Planning
Premature Optimization (Knuth's Optimization Principle)
Premature optimization is the root of all evil.
Architecture
Hyrum's Law
With a sufficient number of API users, all observable behaviors of your system will be depended on by somebody.
Quality
The Boy Scout Rule
Leave the code better than you found it.
Design
YAGNI (You Aren't Gonna Need It)
Don't add functionality until it is necessary.
Teams
Brooks's Law
Adding manpower to a late software project makes it later.
Architecture
Gall's Law
A complex system that works is invariably found to have evolved from a simple system that worked.
Architecture
The Law of Leaky Abstractions
All non-trivial abstractions, to some degree, are leaky.
Architecture
Tesler's Law (Conservation of Complexity)
Every application has an inherent amount of irreducible complexity that can only be shifted, not eliminated.
Architecture
CAP Theorem
A distributed system can guarantee only two of: consistency, availability, and partition tolerance.
Architecture
Second-System Effect
Small, successful systems tend to be followed by overengineered, bloated replacements.
Architecture
Fallacies of Distributed Computing
A set of eight false assumptions that new distributed system designers often make.
Architecture
Law of Unintended Consequences
Whenever you change a complex system, expect surprise.
Architecture
Zawinski's Law
Every program attempts to expand until it can read mail.
Teams
Dunbar's Number
There is a cognitive limit of about 150 stable relationships one person can maintain.
Teams
The Ringelmann Effect
Individual productivity decreases as group size increases.
Teams
Price's Law
The square root of the total number of participants does 50% of the work.
Teams
Putt's Law
Those who understand technology don't manage it, and those who manage it don't understand it.
Teams
Peter Principle
In a hierarchy, every employee tends to rise to their level of incompetence.
Teams
Bus Factor
The minimum number of team members whose loss would put the project in serious trouble.
Teams
Dilbert Principle
Companies tend to promote incompetent employees to management to limit the damage they can do.
Planning
Parkinson's Law
Work expands to fill the time available for its completion.
Planning
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%.
Planning
Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
Planning
Goodhart's Law
When a measure becomes a target, it ceases to be a good measure.
Planning
Gilb's Law
Anything you need to quantify can be measured in some way better than not measuring it.
Quality
Murphy's Law / Sod's Law
Anything that can go wrong will go wrong.
Quality
Postel's Law
Be conservative in what you do, be liberal in what you accept from others.
Quality
Broken Windows Theory
Don't leave broken windows (bad designs, wrong decisions, or poor code) unrepaired.
Quality
Technical Debt
Technical Debt is everything that slows us down when developing software.
Quality
Linus's Law
Given enough eyeballs, all bugs are shallow.
Quality
Kernighan's Law
Debugging is twice as hard as writing the code in the first place.
Quality
Testing Pyramid
A project should have many fast unit tests, fewer integration tests, and only a small number of UI tests.
Quality
Pesticide Paradox
Repeatedly running the same tests becomes less effective over time.
Quality
Lehman's Laws of Software Evolution
Software that reflects the real world must evolve, and that evolution has predictable limits.
Quality
Sturgeon's Law
90% of everything is crap.
Scale
Amdahl's Law
The speedup from parallelization is limited by the fraction of work that cannot be parallelized.
Scale
Gustafson's Law
It is possible to achieve significant speedup in parallel processing by increasing the problem size.
Scale
Metcalfe's Law
The value of a network is proportional to the square of the number of users.
Design
DRY (Don't Repeat Yourself)
Every piece of knowledge must have a single, unambiguous, authoritative representation.
Design
KISS (Keep It Simple, Stupid)
Designs and systems should be as simple as possible.
Design
SOLID Principles
Five main guidelines that enhance software design, making code more maintainable and scalable.
Design
Law of Demeter
An object should only interact with its immediate friends, not strangers.
Design
Principle of Least Astonishment
Software and interfaces should behave in a way that least surprises users and other developers.
Decisions
Dunning-Kruger Effect
The less you know about something, the more confident you tend to be.
Decisions
Hanlon's Razor
Never attribute to malice that which is adequately explained by stupidity or carelessness.
Decisions
Occam's Razor
The simplest explanation is often the most accurate one.
Decisions
Sunk Cost Fallacy
Sticking with a choice because you've invested time or energy in it, even when walking away helps you.
Decisions
The Map Is Not the Territory
Our representations of reality are not the same as reality itself.
Decisions
Confirmation Bias
A tendency to favor information that supports our existing beliefs or ideas.
Decisions
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.
Decisions
The Lindy Effect
The longer something has been in use, the more likely it is to continue being used.
Decisions
First Principles Thinking
Breaking a complex problem into its most basic blocks and then building up from there.
Decisions
Inversion
Solving a problem by considering the opposite outcome and working backward from it.
Decisions
Pareto Principle (80/20 Rule)
80% of the problems result from 20% of the causes.
Decisions
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.