The Eponymous Laws of Computer Science
Ideas so good, they have become the law.
Here is my collection of “laws” and “axioms” concerning software development. Any suggestions or corrections would be greatly appreciated.
Augustine’s 30th Law
The weaker the data available upon which to base one’s conclusion, the greater the precision which should be quoted in order to give the data authenticity. — Norman R. Augustine
Atwood’s Law
Any application that can be written in JavaScript, will eventually be written in JavaScript. — Jeff Atwood
Beizer’s Law
Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. — Bruce Beizer
Bradley’s Law of Innovation
With any emerging movement, it is those that can identify and exploit what’s different and not those who focus on what’s the same, who will innovate and drive change. — Anthony J. Bradley
Brook’s Law
Adding human resources to a late software project makes it later. — Fred Brooks
Bye’s First Law of Model Railroading
Anytime you wish to demonstrate
something, the number of faults encountered is proportional to the number of viewers.
Clarke’s 1st Law
When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong. — Arthur C. Clarke
Clarke’s 2st Law
The only way of discovering the limits of the possible is to venture a little way past them into the impossible. — Arthur C. Clarke
Clarke’s 3st Law
Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke
Conway’s Law
Any piece of software reflects the organizational structure that produced it. — Melvin Conway
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
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
Eagleson’s Law
Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else — Peter S. Eagleson
Edwards’ Law
You cannot apply a technological solution to a sociological
problem.
Ellison’s Law of Cryptography and Usability
The user base for strong cryptography declines by half with every additional keystroke or mouseclick required to make it work. — Carl Ellison
Fitt’s Law
The time to acquire a target is a function of the distance to and size of the target. — Paul Fitts
Fundamental Theorem of Software \Engineering
We can solve any problem by introducing an extra level of indirection. — Andrew Koenig
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 working simple system. — John Gall
Godwin’s Law
As an online discussion grows longer, the probability of a comparison involving Hitler approaches 1. — Mike Godwin
Greenspun’s Tenth Rule
Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. — Philip Greenspun
Gustafson’s Law
Any sufficiently large problem can be efficiently parallelized. — John Gustafso
Haack’s Law
Work expands so as to overflow the time available and spill on the floor leaving a very sticky mess. — Phil Haack
Hanlon’s Razor
Never attribute to malice that which is adequately explained by stupidity. — Robert Hanlon
Hartree’s Law
Whatever the state of a project, the time a project-leader will estimate for completion is constant. — Douglas Hartree
Hick’s Law
The time and the effort it takes to make a decision, increases with the number of options. — William Edmund Hick
Hoare’s Law of Large Programs
Inside every large program is a small program struggling to get out. — Tony Hoare
Hofstadter’s Law
Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law. — Douglas Hofstadter
Jakob’s Law of the Internet User Experience
Users spend most of their time on other sites. — Jakob Nelson
Joy’s Law
No matter who you are, most of the smartest people work for someone else. — Bill Joy
Kerchkhoff’s Principle
A cryptographic system should be designed to be secure, even if all its details, except for the key, are publicly known. — Auguste Kerckhoff
Kernighan’s Law
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. — Brian Kernighan
Linus’s Law
Given enough eyeballs, all bugs are shallow. — Linus Torvalds
Lister’s Law
People under time pressure don’t think faster. — Timothy Lister
Lubarsky’s Law of Cybernetic Entomology
There’s always one more bug.
McLuhan’s Law
If it works it’s obsolete.
Metcalfe’s Law
In network theory, the value of a system grows as approximately the square of the number of users of the system. — Robert Metcalfe
Moore’s Law
The number of transistors on an integrated circuit will double in about 18 months. — Gordon Moore
Murphy’s Law
Anything that can go wrong will go wrong
Nathan’s First Law
Software is a gas; it expands to fill its container. — Nathan Myhrvol
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
Pareto Principle
80% of the effects come from 20% of the causes. — Vilfredo Pareto
Parkinson’s Law
Work expands so as to fill the time available for its completion. — C. Northcote Parkinson
Parkinson’s Law of Triviality
The time spent on any item of the agenda will be in inverse proportion to the sum of money involved. — C. Northcote Parkinson
The Peter Principle
In a hierarchy, every employee tends to rise to his level of incompetence. — Laurence J. Peter
Postel’s Law
An implementation should be conservative in its sending behavior, and liberal in its receiving behavior. — Jon Postel
Putt’s Law
Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand. — Archibald Putt
Reed’s Law
The utility of large networks, particularly social networks, can scale exponentially with the size of the network. — David P. Reed
Sayre’s Law
In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake. — Wallace Sayre
Spafford’s Adoption Rule
For just about any technology, be it an operating system, application or network, when a sufficient level of adoption is reached, that technology then becomes a threat vector. — George Spafford
Spector’s Law
The time it takes your favorite application to complete a given task doubles with each new revision. — Lincoln Spector
Stigler’s Law of Eponymy
No scientific discovery is named after its original discoverer. — Stephen Stigler
Sturgeon’s Law
Ninety percent of everything is crap. — Theodore Sturgeon
Weinberg’s Second Law
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. — Gerald Weinberg
Wirth’s Law
Software is getting slower more rapidly than hardware is getting faster. — Niklaus Wirth
Zawinski’s Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. — Jamie Zawinski
Ziv’s Law
Software development is unpredictable and that the documented artifacts such as specifications and will never be fully understood.
If you want more, I have a channel full of Python and Linux video tutorials on Youtube.