Principles
- 1
Software is meaning made executable.
- 1.1
The meaning of a thing is what it is, what it may become and what may be done with it.
- 1.11 The conditions a thing can be in are its states. What may be done with it are its operations, and which are allowed depends on its state.
- 1.2
Software is built by composition.
- 1.3
Every part carries assumptions about data, effects and failure.
- 1.4
The cost of software lies as much in the joins as in the parts.
- 1.1
- 2
Whatever meaning is left unstated is guessed.
- 2.1
Whoever writes the code makes the guess.
- 2.2
An agent is a model that writes code. It changes what code costs, not what code must do.
- 2.21 When code is cheap, guesses multiply.
- 2.3
An agent builds on the foundation it is given: the parts, conventions and language around it.
- 2.4
Mistakes are certain. Their kinds are not.
- 2.41 A foundation decides which kinds are prevented, which are exposed and which get through.
- 2.5
A review is a judgement, not a proof.
- 2.1
- 3
Correctness must be made explicit.
- 3.1
Software is correct when it does what its meaning says.
- 3.11 Correctness can be judged only against meaning that is stated.
- 3.2
An instruction can be ignored. A check cannot.
- 3.3
An ontology makes meaning explicit: what each thing is, and how each relates to the rest.
- 3.4
Every state a thing can take must be named.
- 3.41 An unnamed state is handled by accident, or not at all.
- 3.5
External input is untrusted until it is validated.
- 3.51 Data is validated once, where it enters.
- 3.6
A part may cause only the effects it is given.
- 3.61 What is given can be replaced: a part can be tested without the world it touches.
- 3.1
- 4
A language decides what can be stated.
- 4.1
Types describe the states data can take and the operations allowed on it.
- 4.11 When types name every state, a forgotten case is found before the code runs.
- 4.12 Types draw boundaries no code can cross.
- 4.13 Invalid states must be unrepresentable.
- 4.14 Once validated, data carries what was checked in its type.
- 4.15 Not every rule of a domain fits in a type. Every rule that fits belongs there.
- 4.2
Code must state plainly what it means to do.
- 4.21 A person can judge only what the code makes plain.
- 4.3
A language is one layer of a foundation, not the whole of it.
- 4.4
What types cannot rule out must be tested.
- 4.5
What tests cannot settle must be observed.
- 4.51 Load, timing and the real shape of data are known only in operation.
- 4.6
Reliability comes in layers, not from any single mechanism.
- 4.61 Each layer catches errors the one before it lets through.
- 4.1
- 5
A coherent foundation does each thing one way.
- 5.1
Coherent conventions reduce arbitrary choices.
- 5.11 Every arbitrary choice is a chance to be wrong.
- 5.2
Parts designed together compose without translation.
- 5.21 Data, effects and failure are modelled one way across every part.
- 5.3
One canonical approach is worth more than several good ones.
- 5.4
Tests that travel with a part preserve what was learned in building it.
- 5.41 A foundation is trusted when its parts are tested together.
- 5.5
Every part says how it is meant to be used.
- 5.51 Its types turn that statement into a check.
- 5.1
- 6
What can be computed must not be guessed.
- 7
What the language cannot say, the system cannot get wrong.
