The Eponymous Laws of Computer Science

Jason Rigden
5 min readSep 20, 2017

--

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.

--

--

Jason Rigden

You may remember me from such projects as The Seattle Podcasters Guild, The Talking Cryptocurrency Podcast, or some of my popular Python tutorials.