Skip navigation

For a class I’m teaching, I’d like to collect a list of favorite “maxims” or “aphorisms” for computer systems.

I’d be very grateful if you would add your favorites below to the comments, preferably with a link to a source that either introduces or references the maxim.  It’s OK to agree or disagree with the maxim.

I’d enjoy seeing people’s support/critiques for these below as well — may merit more focused posts another day.


What else?


  1. Courtesy @vshukla: Lamport on “Teaching Concurrency” (invariants) and Dijkstra’s Turing lecture.… and

  2. I am pretty sure that I stole this from Keith Bostic: You should remove code in every release. Really great systems get smaller over time.

    From the lore: Complex systems have no obvious bugs. Simple systems obviously have no bugs.

    The way to build reliable systems is to build unreliable systems and then get some users. You should test, but you can never test enough.

    “Right in theory” is respectable, but “works in practice” is better.

  3. Andy Tanenbaum says “Ontogeny Recapitulates Phylogeny”

    Click to access sample-1.pdf

    • I hadn’t seen that. Hilarious!

  4. “Worse is Better” is a good one (

  5. Computers are like Old Testament gods; lots of rules and no mercy. ~Joseph Campbell

    Three things are certain:
    Death, taxes, and lost data.
    Guess which has occurred.

    After growing wildly for years, the field of computing appears to be reaching its infancy. ~John Pierce

    A computer lets you make more mistakes faster than any invention in human history – with the possible exceptions of handguns and tequila. ~Mitch Ratcliffe

    A complex system that works is invariably found to have evolved from a simple system that works.

    Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. ~Doug Gwyn

    First make it work, then make it fast – Bruce Eckel:

    Premature optimization is the root of all evil. – C. A. R. Hoare

    write stupid code that uses smart data

    bunch more here

  6. It would be a pity not to include Peter Deutsch’s eight fallacies of distributed computing:

  7. “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, “The Elements of Programming Style”, 2nd edition, chapter 2

    “The three chief virtues of a programmer are: Laziness, Impatience and Hubris.”
    Larry Wall

    “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” – Phil Greenspun. `Greenspun’s 10th rule`

    “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable. ” – Leslie Lamport

    “If they can’t just stick it on the web and let people use it, it’s probably not baked.” — heard from Sam Pullara

    “Beware of bugs in the above code; I have only proved it correct, not tried it.” — Donald E. Knuth

    Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
    -Jamie Zawinski, in comp.emacs.xemacs

    Joe, you probably know the true origin of this, but I’m pretty sure Stonebraker had a pithy saying about mapping applications to database is like “gluing an apple to a pancake”

    “If you don’t find it in the index, look very carefully through the entire catalogue.” — actually from the Sears, Roebuck, and Co., Consumer’s Guide, 1897, but I thought it would be amusing as a computing aphorism… =)

    • Leonardo Ribeiro
    • Posted September 29, 2011 at 7:01 am
    • Permalink
    • Reply

    Tape is dead. Disk is tape. Flash is disk. RAM locality is King.
    Jim Gray

  8. “When in doubt, leave it out” — used to fight (premature) addition of features

    “When in doubt, take the path that’s easiest to undo” (generalization of the above, actually) — especially helpful early in a project, when the learning-curve is steep. Rather than burn lots of time trying to figure out The Right Answer (and probably getting it wrong anyways), find a clever way to buy time to climb the learning curve by going with an interim solution that’s cheap to undo.

    “Audit, Patch, and Bootstrap” — checklist for real-world replication. Explained here: (my lame attempt at blogging)

  9. There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

    — C.A.R. Hoare, The 1980 ACM Turing Award Lecture

  10. The key to performance is elegance, not battalions of special cases.

    — Jon Bentley and Doug McIlroy

  11. My favorite one (found on Oprofile Website):
    Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is. – Rob Pike

    Moore’s Law , Amdahl’s Law, and Dennard’s Scaling.'s_law

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: