Software architecture rules and effects

✍️ Written on 2021-01-07 in 944 words. Part of cs software-development

Update 2021-01-18: thanks to Karl Voit for mentioning “Law of the instrument” to me.
Update 2021-01-25: Hyrum’s Law added.
Update 2021-11-23: Robustness principle added.
Update 2022-04-28: Lehman’s law added.
Update 2022-12-11: Law of Demeter added.

Motivation

I just wanted to make a summary of established (humorous or not) software architecture rules, effects and principles.

Rules, effects, and principles

Airplane rule

“Complexity increases the possibility of failure; a twin-engine airplane has twice as many engine problems as a single-engine airplane”

Brooks’s law

“Adding manpower to a late software project makes it later”

Conway’s law

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”; or by Eric S. Raymond “If you have four groups working on a compiler, you’ll get a 4-pass compiler”

Command–query separation (CQS)

principle of imperative computer programming stating that every method should either be a command that performs an action, or a query that returns data to the caller, but not both.

Don’t repeat yourself

principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.

Finagle’s law of dynamic negatives or Murphy’s law

“Anything that can go wrong, will—at the worst possible moment”

Formosa’s Law

“The truly insane have enough on their plates without us adding to it”

Godwin’s law

“As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one”

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

Hofstadter’s law

“It always takes longer than you expect, even when you take into account Hofstadter’s Law”

Hyrum’s Law

“With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.”

Keep It Simple, Stupid

most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided

Law of the instrument

”I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

Lehman’s laws of software evolution

8 laws labelled {Continuing Change, Increasing Complexity, Self Regulation, Conservation of Organisational Stability, Conservation of Familiarity, Continuing Growth, Declining Quality, Feedback System}

Lindy effect

“Mortality rate of technology decreases with time”

Moore’s law

“the number of transistors in a dense integrated circuit (IC) doubles about every two years”

Ninety-ninety rule

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time”

Parkinson’s law

“work expands so as to fill the time available for its completion” or (… law for Data) “Data expands to fill the space available for storage”

Robustness Principle

“be conservative in what you do, be liberal in what you accept from others”

Second-system effect

the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence

Single source of truth

practice of structuring information models and associated data schema such that every data element is mastered (or edited) in only one place

Small matter of programming (SMOP)

“A piece of program code, not yet written, whose anticipated length is significantly greater than its intellectual complexity”. It often implies that the person proposing the feature underestimates its cost.

Software Peter principle

describes a dying project which has become too complex to be understood even by its own developers

Sturgeon’s law

“ninety percent of everything is crap”

Turing tarpit

any programming language or computer interface that allows for flexibility in function but is difficult to learn and use because it offers little or no support for common tasks (“Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy”)

Wirth’s law

“software is getting slower more rapidly than hardware is becoming faster”

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

Zero one infinity (ZOI) rule

“Allow none of foo, one of foo, or any number of foo” ⇒ “The only reasonable numbers are zero, one and infinity.”

Law of Demeter

“Each unit should have only limited knowledge about other units. Each unit should only talk to its friends; don’t talk to strangers.”

Conclusion

This was an interesting, biased list itself. In this context, 50 Cognitive Biases to be Aware of so You Can be the Very Best Version of You is also interesting.