Wisdoms, aphorisms, and pointed observations — fragments I find myself frequently quoting in conversations about software, philosophy, and ways of working.
Chesterton’s fence
Reforms should not be made until the reasoning behind the existing state of affairs is understood.
Gell-Mann amnesia effect
The Gell-Mann amnesia effect is a cognitive bias describing the tendency of individuals to critically assess media reports in a domain they are knowledgeable about, yet continue to trust reporting in other areas despite recognizing similar potential inaccuracies.
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.
Hyrum’s law (the law of implicit interfaces)
With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.
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.
Occam’s razor
Entities should not be multiplied without necessity.
Parkinson’s law
Work expands so as to fill the time available for its completion.
Ringelmann effect
It’s the tendency of an individual to become increasingly inefficient as more and more people are involved in a task. In other words, as more individuals are added to a team, the more the average individual performance decreases.
The Beyoncé rule
If you want to be confident that a system exhibits a particular behavior, the only way to be sure it will is to write an automated test for it. Google calls it the Beyoncé Rule. Succinctly, it can be stated as follows: “If you liked it, then you shoulda put a test on it.”
The law of conservation of complexity (Tesler’s law)
There is a certain amount of complexity in a system which cannot be reduced.
The law of leaky abstractions
All non-trivial abstractions, to some degree, are leaky.
The law of the instrument
If all you have is a hammer, everything looks like a nail.
The law of triviality
Groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
The principle of least astonishment
People are part of the system. The design should match the user’s experience, expectations, and mental models.
The Unix philosophy
Software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.