Laws in computer science

On this page

None of these are laws of nature. They are observations that people keep making, decade after decade, because they keep coming true.

Performance and scale

Amdahl’s Law: The serial part of a program caps its speed-up, no matter how many processors you add — Gene Amdahl, 1967 · → Learn more
Moore’s Law: “The complexity for minimum component costs has increased at a rate of roughly a factor of two per year” — Gordon Moore, 1965 · → Learn more
Wirth’s Law: “Software is getting slower more rapidly than hardware is becoming faster” — Niklaus Wirth, 1995
Pareto Principle: For many events, roughly 80% of the effects come from 20% of the causes — Vilfredo Pareto; named by Joseph Juran
Reed’s Law: “The utility of large networks, particularly social networks, can scale exponentially with the size of the network” — David P. Reed, 1999
Little’s Law: The average number of items in a queue equals the average arrival rate times the average time each item spends in it — John Little, 1961
Knuth’s Optimization Principle: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil” — Donald Knuth, “Structured Programming with go to Statements”, 1974

Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations” — Melvin Conway, 1968
Brooks’s Law: “Adding manpower to a late software project makes it later” — Fred Brooks, The Mythical Man-Month, 1975
Parkinson’s Law: “Work expands so as to fill the time available for its completion” — C. Northcote Parkinson, 1955
Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law” — Douglas Hofstadter, Gödel, Escher, Bach, 1979
The Ninety-Ninety Rule: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time” — Tom Cargill, Bell Labs
The Peter Principle: “In a hierarchy, every employee tends to rise to his level of incompetence” — Laurence J. Peter, 1969
Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure” — Charles Goodhart, 1975; phrased by Marilyn Strathern, 1997

Gall’s Law: “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a simple working system” — John Gall, Systemantics, 1975
Dijkstra’s Law: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better” — Edsger W. Dijkstra, 1984
Postel’s Law: “Be conservative in what you send, be liberal in what you accept” — Jon Postel, RFC 761, 1980
Hyrum’s Law: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody” — Hyrum Wright, Google
Kernighan’s Law: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” — Brian Kernighan and P. J. Plauger, The Elements of Programming Style, 1978
The Law of Leaky Abstractions: “All non-trivial abstractions, to some degree, are leaky” — Joel Spolsky, 2002
Murphy’s Law: “Anything that can go wrong will go wrong” — Attributed to Edward A. Murphy Jr., 1949

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” — Ward Cunningham; named by Steven McGeady
Sturgeon’s Law: “Ninety percent of everything is crud” — Theodore Sturgeon, 1958