This is a list of common-sense axioms and wisdom that universally apply to CS. It’s the CS-based version of this page.
Universals
Roosevelt’s Law of Task Planning – Work with what you have, not with what you hope to have or might exist later.
Since computers advance so fast, all previous analysis and efforts were made in a different time period, so anything over a year old is the soft social science of history.
There’s no universal ideal solution, but there are ideals for use cases. There are also more wrong solutions than right ones.
You only legitimately understand something either the third time you see it or the first time you teach it.
You’ll never have all the information, so start the analysis as soon as possible and reconfigure often.
Make guesses when in doubt, guess in an emergency, but always clean up the mess later.
You’re not as smart or experienced as everyone else in the industry. If your analysis says your prototype will run faster than Google, you may have invented a new mathematical proof, but it’s more likely you missed something.
Clarke’s Third Law – Sufficiently advanced technology looks the same as magic.
Kranzberg’s First Law of Technology – Technology has no value of good, bad, or neutral.
Maes-Garreau Law – The nearest predictions about large-scale future technology tends to be right before the predictor imagines they’ll die.
Technology Life Cycle – Every invented technology is first not that useful, then becomes more useful up to a point, then becomes less useful as other technology replaces it, until it becomes generally obsolete.
Van Loon’s Law – Societies develop technology when they can’t make people do things for them.
Dev/Design
Atwood’s Law – If it can be, it eventually will be written in JavaScript.
Cupertino Effect – The stupidity of computers means they’ll frequently override a common use case (like “cooperation”) for an obscure one (like “Cupertino” instead of “co-operation”).
de Saint-Exupery’s Law of Design – A designer doesn’t achieve perfection when there’s nothing left to add, but when there’s nothing left to take away.
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.
- Morris’ Corollary – This includes Common Lisp.
Kranzberg’s Third Law of Technology – Technology breaks apart into “packages”.
Liskov Substitution Principle – When inserted into a system, a subtype must be interchangeable with its parent type (e.g., if Type B is a subtype of Type A, then Type A can fit into everything that Type B fits into).
Miller’s Law – All large-group discussions about a small software update will eventually include discussing giant redesigns, adding features, or replacing that software.
Shea’s Law – The most significant design improvements are in its interface, but are also the easiest to screw up.
Unix Philosophy – The best-designed computer program is made to do 1 thing well, which will include sending out a standardized flow of text information.
von Tiesenhausen’s Law of Engineering Design – To share your understanding, learn to draw, since the finished product for some reason always ends up looking like the concept art.
Zawinski’s Law – Every program keeps expanding until it can read mail (i.e., long-form time-insensitive messages), or will be replaced by ones that can.
Designing something better than requirements is completely uncorrelated to the final product’s quality.
Requirements come from the ability to “do” things, no matter what engineering textbooks say.
The fastest way to solve something is often to throw out everything and start over.
Improvements/Debugging
Amdahl’s Law – The improvement of any given component of a system will only make an effective improvement proportionally to how much it’s used in that system.
Haitz’s Law – Every decade, each LED’s cost per lumen is divided by 10 and becomes 20 times more efficient.
Linus’ Law – Given enough eyeballs, all bugs are trivial.
Kernighan’s Law – Debugging a program is twice as hard as writing it, so simple code is better than complex code.
Claasen’s Law – Incrementally more technology means exponentially more results.
Hardware
IETF Motto – Be precise in what you send, flexible in what you receive.
Grosch’s Law – The relative speed increase of a computer is the square of its relative increased cost.
Klaiber’s Law – The silicon wafer’s size proportionally dictates the largest diameter of ultra-pure water piping necessary for a semiconductor wafer factory.
Marconi’s Law – The effective distance of an antenna tower is approximately the height of the antenna squared.
Moore’s Law – Computers become twice as powerful every 2 years, which compounds to 32x over a decade.
The only place where improvements in a chain of dependencies matter are on the slowest components.
The optimum is almost always somewhere in the middle in nature, so distrust assertions that the optimum on a graph is at an extreme point.
System Growth
Cooper’s Law of Spectral Efficiency – The maximum number of simultaneous flows of information across a medium doubles every 30 months.
Hyrum’s Law / Law of Implicit Interfaces – When there are enough API users, someone will have to maintain every single aspect of that API, irrespective of what a public contract indicates.
Koomey’s Law – The number of computations for energy doubles every 1.57 years, which compounds to 100x over a decade.
Lindy Effect – The longer a technology has been around, the longer it will persist before becoming obsolete.
Metcalfe’s Law – A system’s value grows at about the square of the number of users in the system.
Wirth’s Law – Over time, software gets slower faster than hardware gets faster.
Fixing Things
Hacking and coding is an analytical creative art pursuing vague goals, so it’s not worth taking failure personally.
Working
Don’t use a company account to sign up for something if you plan to use that service longer than staying with the company (which is very likely).
Unless you enjoy the experience, only make a productivity-enhancing system if the work to do it takes less time than the time you save over a year.
Trends
The unwashed masses don’t understand computers, but they vote with their wallet, so the tech industry is run by the tyranny of the majority.
The people who build out the winning tech trends are some random guy name Ronald who makes a Unix-based software package called “runk” that stands for “Ronald’s Universal Number Kounter”. Then, big names like Bill Gates and Steve Jobs streamline it and sell it at enormous profit.
Distributed Systems
Brewer’s Theorem / CAP Theorem – for any distributed data storage, only 2 of 3 guarantees are possible:
- Consistency – every request returns the most recent data or an error.
- Availability – every request returns data without an error, even if it’s not the most recent.
- Partition Tolerance – everything still works even when nodes fail.
- An addition is PACELC, which adds 2 variables in the case of node failure (E, for “else”):
- Latency – partially-working systems can prioritize staying fast.
- Consistency – partially-working systems can prioritize sending consistent data.
Internet-Specific
1% Rule/1-9-90 Rule – On a user-generated website (like a wiki) only 1% of people create content, another 9% contribute somewhat, while the other 90% only consume.
Cunningham’s Law – Instead of asking a question, the best way to get the right answer on the internet is to give the wrong answer.
Godwin’s Law – As online discussions grow, it’ll eventually guarantee comparing someone to Nazis or Hitler.
Lewis’ Law – Publicly announcing a perceived injustice that’s controversial invariably means the comments will justify that idea.