A linked reference to the hard-to-define rules of software design. Each entry gives the primary source, the claim it makes, the strength of the evidence, and the principles it fights with.
Most of these principles answer the same three questions: where knowledge lives, how far a change spreads, and how quickly you find out you were wrong. The interesting part is where they disagree, and the tensions section sets those conflicts side by side.
The whole list in one table. For each principle it shows the theme, the strength of the evidence, the ideas it is related to, and the positions it conflicts with. The search and filters above apply here too.
| Principle | Theme | Evidence | Related to | In tension with |
|---|
No principle wins everywhere. Each pair below gives the reason for the conflict, how practitioners usually resolve it, and where the authors stand, with a link to the source for each position.
The ideas in order of publication. Entries marked as responses show where one piece built on or argued against an earlier one, which is how most of these principles got their sharpest form.
Principle-level standards rank trade-offs, explain why, and hand the mechanical rules to tools. These are the clearest published examples.
| Document | What it says at the principle level | How it is made checkable |
|---|
Where a change is approved or refused, what an approval is taken to mean, what large projects require, and what the research says each approach costs.
The record is stronger for system-level structure than for any code-level rule. These are the studies the badges above rest on.
Compiled October 2026. This section will age fastest.
This is not a sixth theme. The five themes are about what makes software good to build and maintain, and a coding standard can take a position on each. Ethics asks who bears the cost when the software runs. That is a separate discussion with its own literature, so it is kept apart here. Where a principle above touches it, the entries link across.
A continuation of the ethics discussion: what other professions require of their members, why software has no equivalent, how aviation handles error, what the law gives people who speak up and what happened to those who did, and which protections are still missing. It summarises law for orientation and is not legal advice.