Naming
Before naming anything that will be reused, find out what it is already called — a shortlist of invented names is a skipped lookup, not creativity.
Trigger: you are about to name or number something that will be reused — an identifier scheme, a document type, a process phase, a folder layout, a status set, a unit of work, a severity scale.
Stop and look it up before writing a single candidate.
Project management, requirements engineering, construction, law, medicine, library science and manufacturing have been doing this for decades and have settled words. If a discipline has done the thing for thirty years, it has a name for it — and that name beats yours.
The rules
- Name the practice you found, say which you are adopting, and where it comes from.
- Adopt the standard word even when it is less pretty. Recognition beats elegance: a word someone can look up is worth more than one they have to be taught.
- Depart only with a stated reason — a real collision, or the standard genuinely not fitting. "I prefer mine" is not a reason.
- Say plainly when there is no standard. That is a legitimate finding, and then invent.
- Standards live at the boundary. Adopt an industry word when it is also the plain word. Otherwise keep the plain word in the core and map to the standard in the adapter, where the integrator actually meets it.
Red flags — stop
- "Let's call it…" before any search.
- Presenting options for a name rather than for a decision.
- A coding scheme derived from initials — it collides, and it needs a legend.
- Any identifier that needs a lookup table to be read.
- Inventing a phase, a status set or a severity scale from scratch.
Where to look first
These are the ones that come up most, with what they settle. The list is a starting point, not a boundary — see standards adopted for the ones already in force here.
| Practice | Settles |
|---|---|
| WBS (work breakdown structure) | How work is numbered and decomposed |
| ADR / MADR | How a structural decision is recorded |
| Diátaxis | How documentation is divided by reader need |
| arc42, C4 | How an architecture is described and drawn |
| Volere, CMMI REQM | How a requirement is shaped and traced |
| Gherkin | How an acceptance criterion is phrased |
| RACI | Who is responsible, accountable, consulted, informed |
| MoSCoW | How priority is expressed |
| Semantic versioning | What a version number promises |
| RFC 2119 | What must, should and may mean in a normative sentence |
| Tracer bullet | How a first vertical slice is sized |
| Expand → migrate → contract | How a wide refactor is sliced without breaking the build |
| Domain Storytelling, EventStorming | How a domain is discovered rather than organised |
The lexicon
Where the domain vocabulary is not English, carry a lexicon: business term ↔ English identifier, one translation per term, stated once and normative.
Without it the ubiquitous language dies at the first synonym — two developers
translate demande as Request and Application, and the model quietly forks.
The lexicon is also where the industry word is chosen deliberately
(jurisdiction, not Competence), which is the boundary rule applied to naming.
Rationalisations
| Excuse | Reality |
|---|---|
| "There is no standard word for this" | Say that only after looking. Most of what feels novel is a solved naming problem. |
| "The standard word is ugly / too formal" | Recognition beats elegance. A word someone can look up beats one they must be taught. |
| "Our version is clearer" | Clearer to you, today. A name is read by people who were not in the conversation. |