Skip to content

Engineering laws

Jump to bottom
Gabor Szarnyas edited this page Jun 15, 2022 · 24 revisions

Laws

  • Phil Karlton's law: "There are only two hard things in Computer Science: cache invalidation and naming things."

    This spawned a couple of others, for example:

    • Mathias Verraes: "There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery"

  • Zawinski's law of software envelopment: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can [read email]."

  • An updated version of Zawinski's law: "Every mobile app attempts to expand until it includes chat. Those applications which do not are replaced by ones which can [provide chat features]."

  • Sturgeon's law: "Ninety percent of everything is crap."

  • Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."

  • Atwood's law: "any application that can be written in JavaScript, will eventually be written in JavaScript."

  • Linus's law: "given enough eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."

  • Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

    • Robert Morris' amendment: "Including Common Lisp."

  • Arthur C. Clarke's third law: Any sufficiently advanced technology is indistinguishable from magic.

  • Brian W. Kernighan and Dennis M. Ritchie's famous C programming book on learning a programming language: "The only way to learn a new programming language is by writing programs in it."

  • C. A. R. Hoare's law: "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. The first method is far more difficult."

  • 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."

  • Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."

  • Hofstadter's law: "It always takes longer than you expect, even when you take into account Hofstadter's Law."

  • Metcalfe's law: "The effect of a telecommunications network is proportional to the square of the number of connected users of the system (n²)."

  • Parkinson's law: "Work expands so as to fill the time available for its completion."

  • 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."

  • Brandolini's law (a.k.a. the bullshit asymmetry principle): "The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it."

Principles:

  • Kerckhoffs's principle: "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

Misc

Observations

My observation (Gabor Szarnyas): when you start using an open-source software project, you soon encounter a problem that is very difficult to tackle with the current stable version, but will have an elegant, 'out-of-the-box' solution in one of the project's future releases. This is usually promised in the roadmap of the projects or just mentioned casually on the issue ticket that you found.

Related to this, I recommend reading Chapter 3, Section 2.2 of the How to be a programmer book, "How to Manage Third-Party Software Risks":

[...] project often depends on software produced by organizations that it does not control. There are great risks associated with third party software that must be recognized by everyone involved. Never, ever, rest any hopes on vapor. Vapor is any alleged software that has been promised but is not yet available. This is the surest way to go out of business. It is unwise to be merely skeptical of a software company's promise to release a certain product with a certain feature at a certain date; it is far wiser to ignore it completely and forget you ever heard it. Never let it be written down in any documents used by your company.

Clone this wiki locally