Software Architecture Principles and Quotes
This document contains a curated collection of software architecture principles, design philosophies, and engineering wisdom from various experts in the field.
Core Design Principles
Fundamental Rules
| Principle |
Description |
Source |
| Rule of Zero, One or Infinity (ZOI) |
Arbitrary limits on the number of instances of a particular entity should not be allowed |
Willem van der Poel |
| Worse is better |
Design for simplicity |
Richard P. Gabriel, 'Lisp: Good News, Bad News, How to Win Big' (1989) |
| Uniform Access Principle |
Services should be offered through uniform interfaces, regardless of internal implementation |
Bertrand Meyer |
| Rule of Least Power |
Use the least powerful language possible for a given problem. Prefer declarative languages over procedural |
- |
| Rule 3.14 |
Nothing gets standardised until there are multiple instances of running code |
RFC1958 (1996) |
Classical Engineering Wisdom
| Quote |
Attribution |
| "I can get another if I break it, so a clay cup trumps a grail" |
Mirza Asadullah Khan Ghalib, classical Urdu and Persian poet from the Mughal Empire |
| "Firmitas, utilitas, venusitas. (Firmness, utility, delight)" |
Marcus Vitruvius, 'De Architectura' (22BCE) |
| "There is no excellent beauty which hath not some strangeness in the proportion" |
Francis Bacon |
Trade-offs and Constraints
| Principle |
Description |
| Fast, cheap, and reliable |
choose two |
| Freedom, security, and convenience |
choose two |
| Law of Diminishing Returns |
If one factor of production is increased while the others remain constant, the overall returns will relatively decrease after a certain point |
Software Architecture Paradoxes
| Paradox |
Description |
Source |
| Paradox #1: Flexibility breeds complexity |
We aim to design flexible software; yet, in doing so, we see an undesirable increase in complexity |
Kirk Knoernschild (2012) |
| Paradox #2: Reuse complicates use |
We strive to develop reusable software, only to impair the software's ease of use |
Kirk Knoernschild (2012) |
| Paradox #3: Evolution impedes survival |
We design a software system that can evolve, but in doing so hasten its death |
Kirk Knoernschild (2012) |
Security and Trust
Core Security Concepts
| Concept |
Description |
Source |
| CIA triad |
Confidentiality, Integrity, Availability |
Famous summary of computer security concerns |
| Trust definition |
Trust is the availability of effective recourse |
Dan Geer (2014) |
| Security engineering |
Security engineering is about tolerable failure modes. Determine which failure modes are tolerable and which are not, and design around not having the intolerable ones |
Dan Geer (2014) |
| Shannon's maxim |
One ought to design systems under the assumption that the enemy will immediately gain full familiarity with them |
- |
Programming Philosophy
Code Quality and Design
| Principle |
Description |
Source |
| Programs must be written for people to read |
and only incidentally for machines to execute |
Harold Abelson |
| Any fool can write code that a computer can understand |
Good programmers write code that humans can understand |
Martin Golding |
| Talk is cheap |
Show me the code |
Linus Torvalds |
| Design is the art of arranging code |
to work today, and be changeable forever |
Sandi Metz |
Problem-Solving Approaches
| Quote |
Source |
| "Sometimes the problem is to discover what the problem is" |
Gordon Glegg, 'The Design of Design' (1969) |
| "The besetting mistake of expert designers is not designing the thing wrong, but designing the wrong thing" |
Frederick P. Brooks, 'The Design of Design: Essays from a Computer Scientist' (2010) |
| "All problems in computer science can be solved by another level of indirection, except of course for the problem of too many indirections" |
David Wheeler |
System Design Principles
Butler W. Lampson's Design Guidelines (1983)
Interface Design
| Principle |
Description |
| Do one thing at a time, and do it well |
An interface should capture the minimum essentials of an abstraction. Don't generalize; generalizations are generally wrong |
| If in doubt, leave it out |
- |
| Keep secrets of the implementation |
Secrets are assumptions about an implementation that client programs are not allowed to make |
| Principle |
Description |
| Handle normal and worst cases separately |
The normal case must be fast. The worst case must make some progress |
| Compute in background when possible |
Rapid response is better for users, and there is likely to be idle processor time later |
| Safety first |
In allocating resources, strive to avoid disaster rather than to attain an optimum |
Key Reminders
| Rule |
Description |
| Keep it simple |
- |
| Interfaces to abstractions |
- |
| Write a spec |
- |
Distributed Systems
Leslie Lamport's Insights
| Quote |
Context |
| "A distributed system is one where the failure of a machine you've never heard of stops you from getting any work done" |
- |
| "Success really depends on the conception of the problem, the design of the system, not in the details of how it's coded" |
- |
| "If you're building a complicated system, the battle is won or lost before a single piece of code is written" |
- |
Terry Crowley's Rules of Distributed Systems Design
| Rule |
Description |
| Rule 1 |
Think through the implications to the user experience from the start rather than trying to patch on error handling, cancellation and status reporting as an afterthought |
| Rule 2 |
Use asynchronous techniques to couple components. Synchronous coupling is impossible |
| Rule 3 |
Recognize and explicitly design for interacting state machines |
| Rule 4 |
Failure is expected. The only guaranteed way to detect failure in a distributed system is to simply decide you have waited 'too long' |
| Rule 5 |
Cancellation is not rollback since it is just reclaiming local resources and state |
| Rule 6 |
You can never really know the state of a distributed component |
Unix Philosophy
Mike Garcanz's Unix Philosophy
| Principle |
Description |
| Small is beautiful |
- |
| Make each program do one thing well |
- |
| Build a prototype as soon as possible |
- |
| Choose portability over efficiency |
- |
| Store data in flat text files |
- |
| Use software leverage to your advantage |
- |
| Use shell scripts to increase leverage and portability |
- |
| Avoid captive user interfaces |
- |
| Make every program a filter |
- |
Doug McIlroy's Unix Principles (1978)
| Principle |
Description |
| Do one thing well |
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features |
| Expect composition |
Expect the output of every program to become the input to another, as yet unknown, program |
| Build early |
Design and build software, even operating systems, to be tried early, ideally within weeks |
| Use tools |
Use tools in preference to unskilled help to lighten a programming task |
Unix Wisdom
| Quote |
Source |
| "Those who don't understand Unix are condemned to reinvent it, poorly" |
Henry Spencer |
| "Unix is simple. It just takes a genius to understand its simplicity" |
Dennis Ritchie |
| "When in doubt, use brute force" |
Ken Thompson |
| "One of my most productive days was throwing away 1000 lines of code" |
Ken Thompson |
Eric S. Raymond's Unix Programming Principles
Design Principles
| Principle |
Description |
| Modularity |
Write simple parts connected by clean interfaces |
| Composition |
Design programs to be connected to other programs |
| Separation |
Separate policy from mechanism; separate interfaces from engines |
| Parsimony |
Write a big program only when it is clear by demonstration that nothing else will do |
| Robustness |
Robustness is the child of transparency and simplicity |
| Representation |
Fold knowledge into data so program logic can be stupid and robust |
User Interface Principles
| Principle |
Description |
| Least Surprise |
In interface design, always do the least surprising thing |
| Silence |
When a program has nothing surprising to say, it should say nothing |
| Repair |
When you must fail, fail noisily and as soon as possible |
| Reversibility |
Every operation without an undo is a horror story waiting to happen |
Chinese Wisdom
Chinese Idioms for Software Development
| Chinese |
Pinyin |
English Translation |
Application |
| 不可得兼 |
bù kě dé jiān |
You can't have both at the same time |
Trade-offs |
| 力不从心 |
lì bù cóng xīn |
Frustrated aspirations |
Technical limitations |
| 画蛇添足 |
huà shé tiān zú |
To draw a snake and add legs |
Over-engineering |
| 亡羊补牢 |
wáng yáng bǔ láo |
Better late than never |
Bug fixes |
| 脚踏实地 |
jiǎo tà shí dì |
Tread on solid ground |
Solid foundations |
| 豁然开朗 |
huò rán kāi lǎng |
Eureka! |
Problem-solving moments |
Data-Centric Design
| Quote |
Source |
| "Design the data, not the code" |
Jon Devaan |
| "Bring the computation to the data rather than bringing the data to the computation" |
- |
| "When looking at the structure of a system, I'm less interested in seeing how the code interacts… I want to see how the data interacts and flows" |
Terry Crowley |
| Quote |
Source |
| "In the time that bandwidth doubles, latency improves by no more than a factor of 1.2 to 1.4" |
David Patterson, U.C. Berkeley (2004) |
| "Much of performance analysis is about three things: locality, locality, locality" |
Terry Crowley |
| "An efficient program is an exercise in logical brinkmanship" |
Edsger Dijkstra |
Complexity and Simplicity
Managing Complexity
| Quote |
Source |
| "Successful programming is all about managing complexity" |
Keith Bentley |
| "The unavoidable price of reliability is simplicity. It is a price which the very rich find hard to pay" |
Sir C. A. R. ('Tony') Hoare |
| "The most robust programs isolate complexity in a way that lets significant parts of the system appear simple and straightforward" |
Terry Crowley |
Simplicity Principles
| Quote |
Source |
| "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away" |
Antoine de Saint Exupéry |
| "Do more and more with less and less until eventually you can do everything with nothing" |
Buckminster Fuller |
| "Keep your code absolutely simple. Keep looking at your functions and figure out how you simplify further" |
John Romero, id Software |
Anti-Patterns and Warnings
Common Pitfalls
| Anti-Pattern |
Description |
Source |
| Inner-platform effect |
The tendency to create a system so customizable as to become a replica of the software development platform |
- |
| Second system effect |
The tendency of small, elegant systems to be succeeded by over-engineered, bloated systems |
- |
| RPC fallacy |
Making remote/slow/independent things pretend to be local/fast/fate-shared |
Wes Felter |
Humorous Observations
| Quote |
Source |
| "Some people when faced with a problem think: 'I know, I'll use distributed computing'. Now they have N^2 problems" |
@jamesiry |
| "UML - Unnecessary Management Lingo" |
@iamdevloper |
| "There are only two hard things in Computer Science: off by one errors, cache invalidation and naming things" |
Phil Karlton |
Philosophical Perspectives
Ancient Wisdom Applied
| Quote |
Source |
Context |
| "πάντα ῥεῖ (panta rhei): Everything flows" |
Heraclitus of Ephesus (~535–475BC) |
Change and evolution |
| "The height of cleverness is to be able to conceal it" |
Francois de la Rochefoucauld (1613-1680) |
Interface design |
| "Lest men suspect your tale untrue, keep probability in view" |
John Gay (1727) |
System reliability |
Modern Philosophical Insights
| Quote |
Source |
| "For every proverb, there is an equal and opposite proverb" |
Philip Wadler (2011-03-23) |
| "The only people who see the whole picture, are the ones who step out of the frame" |
Salman Rushdie |
| "Human problems remain human problems, and the higher work of computers doesn't erase that" |
Andrew O'Hagan |
HackMD
