Laws of Software Engineering #

A collection of principles and patterns that shape software systems, teams, and decisions.

56 laws • Click any card to learn more

LevelAll Junior Mid-Level SeniorCategoryAll Architecture Teams Planning Quality Scale Design DecisionsTeams## 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.

CAPArchitecture## 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.

150Teams## 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.

NTeams## 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.

1Teams## 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.

90%+90%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.

1Design## 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.

ABCDesign## 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.

≠MAPREALDecisions## 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.

80%20%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.

No laws found

Try a different search term or clear filters