Bylaws of Programming and Technology

Amara's Law - "We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run."

Amdahl's Law - "The speed-up of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program."

Brooks's Law - "Adding manpower to a late software project makes it later."

Clarke's Three Laws

1. 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.
2. The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
3. Any sufficiently advanced technology is indistinguishable from magic.

(See So Quoted: Any sufficiently... for many corollaries to Clarke's Three Laws.)

Classen's Law - "In order to achieve a linear improvement in usefulness over time it's necessary to have an exponential increase in technology over time." Or more succinctly:

Usefulness = log(Technology)

Conway's Law - "Any piece of software reflects the organizational structure that produced it."

Gall's Law - "A complex system that works is invariably found to have derived from a simple system that worked."

Gates's Law - "The speed of commercial software generally slows by fifty percent every 18 months thereby negating all the benefits of Moore's Law."

Gilder's Law - "Bandwidth grows at least three times faster than computer power."

Goodheart's Law - "When a measure becomes a target, it ceases to be a good measure."

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

Gustafson's Law - "Any sufficiently large problem can be efficiently parallelized."

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

Kerckhoffs' Principle - "A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

Knuth's Law - "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Kranzberg's Six Laws of Technology

1. Technology is neither good nor bad; nor is it neutral.
2. Invention is the mother of necessity.
3. Technology comes in packages, big and small.
4. Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
5. All history is relevant, but the history of technology is the most relevant.
6. Technology is a very human activity - and so is the history of technology.

Linus's Law - "Given enough eyeballs, all bugs are shallow."

Metcalfe's Law - "The value of a system grows as approximately the square of the number of users of the system."

Moore's Law - "The number of transistors that can be inexpensively placed on an integrated circuit doubles roughly every two years."

Norvig's Law - "Any technology that surpasses 50% penetration will never double again (in any number of months)."

Parkinson's Laws

• Work expands so as to fill the time available for its completion.
• Data expands to fill the space available for storage.
• Programs expand to fill all available memory.

Parkinson's Law of Triviality - "Organizations give disproportionate weight to trivial issues."

Proebsting's Law - "Compiler advances double computing power every 18 years."

Reed's Law - "The utility of large networks, particularly social networks, can scale exponentially with the size of the network.

Schneier's Law - "Any person can invent a security system so clever that she or he can't think of how to break it."

Sturgeon's Law - "90% of everything is crap."

Wirth's Law - "Software gets slower faster than hardware gets faster."

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

Buggy Quotes

I've been collecting quotes about programming from all over the internet. Here are a few of my favorites about software bugs.

There has never been an unexpectedly short debugging period in the history of computers.
--Steven Levy

Any sufficiently advanced bug is indistinguishable from a feature.
--Rich Kulawiec

If debugging is the process of removing software bugs, then programming must be the process of putting them in.
--Edsger Dijkstra

As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
--Wilkes, Maurice

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

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

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.
--Douglas Adams

In a software project team of 10, there are probably 3 people who produce enough defects to make them net negative producers.
--Gordon Schulmeyer


These quotes just underscore the fact that programming is error prone and debugging software is hard. Since this is the case, it always amazes me that more people aren't using unit testing as a part of their daily development cycle.

I'm not saying that every developer should religiously follow every tenet laid out in Kent Beck's Test Driven Development, just that a good set of unit tests is a nice safety net to have. It can give you the confidence you need to change your code, knowing that you can always run the tests to make sure you didn't break anything. If you're not making unit tests a part of your daily routine, then why not?