How do you decide how much of the UML diagram taxonomy a team should actually use?
answer
- The taxonomy is a menu, not a checklist
- Every diagram is bought, not free
- Two shelf lives: sketch or kept
- Read by more people than wrote it
- Buy where ambiguity is expensive
basics
~20 sBuy modelling where ambiguity is concentrated and expensive, rather than working through the taxonomy. Most teams need two or three families. Draw in answer to an open question, treat most diagrams as sketches, and keep only what is costly to rediscover.
solid answer
~50 sI treat each diagram as a purchase paid in three instalments — drawing it, every reading of it, and, if it is kept, every reconciliation with reality afterwards — against one benefit, an answer to a question that was genuinely open. That reframes the decision from *which types do we standardise on* to *where is our ambiguity concentrated*. In practice most teams need two or three families, not ten, and the honest split is by shelf life: sketches drawn to settle a conversation and then abandoned, versus a small number of kept models. A model earns keeping only if more people read it than wrote it, it states something expensive to rediscover — a lifecycle whose illegal transitions were learned the hard way — and the design it describes is stable enough to outlive the conversation. Everything else is a sketch, and a sketch is a legitimate finished product.
go deeper
Understand that a quick drawing made to settle a conversation and then abandoned is normal and useful. Not every diagram is meant to be kept or shown to anyone else.
Be ready to say which diagram you would draw for a live disagreement on your team and which you would not bother with, with a reason for each that is about the question, not about completeness.
An interviewer expects you to weigh the recurring cost of a kept diagram against what it saves, and to have declined to draw something on those grounds rather than drawing it to look thorough.
Own the modelling budget as a tradeoff you set deliberately: where the team's ambiguity is, which families you therefore buy, which you never draw, and how you keep the habit coachable rather than mandated.
## Modelling is a purchase, and the price is real The taxonomy lists more diagram types than most teams will ever need, and it is not a checklist. Each diagram a team draws is bought with time in three separate instalments: **the drawing**, **every reading**, and — only if it is kept — **every reconciliation with reality after the design moves on.** The third instalment is the expensive one and is easy to sign up for without noticing, because it recurs while the other two do not. Against that price, a diagram buys exactly one thing: **an answer to a question that was genuinely open.** So the sizing question is not *which diagram types should we standardise on* but *where is the team's ambiguity, and how much would removing it be worth*. Two teams of the same size on the same stack can honestly land in different places, and a leader should be able to say why theirs landed where it did. ## The two shelf lives Almost every diagram is one of two things, and confusing them is where cost leaks: - **A sketch with a shelf life measured in minutes.** Drawn during a conversation to settle a disagreement, read by the people present, and abandoned once the decision is made. Its whole value was in the conversation. It should be cheap, ugly, and not kept. - **A model with a shelf life measured in months.** Read by people who were not there, treated as a statement of what is true, and therefore something that has to keep being true. It has to earn that standing. Most teams over-buy the second because the first feels wasteful. It is not: the throwaway sketch is the highest-return modelling a team does, precisely because it costs almost nothing and never comes back for more. ## Three tests before a diagram is kept 1. **More people will read it than wrote it.** If the audience is the two people who drew it, it was a sketch. A kept diagram is a broadcast. 2. **It states something expensive to rediscover.** A lifecycle whose illegal transitions were learned from an outage is worth keeping. An arrangement anyone can recover in ten minutes of reading is not. 3. **It will outlive the conversation that produced it.** If the design it describes is about to change, keeping it buys a reconciliation bill against a moving target. A diagram that fails any of the three is still worth drawing — as a sketch. ## A worked budget Take a small team on a language-learning app, working a 47-item backlog with a legacy system being decommissioned in parallel. A defensible budget looks like this, and the reasoning matters more than the specific answers: | Modelling need | Family | Verdict | Why | | --- | --- | --- | --- | | Legal lifecycle of a subscription, agreed with the outgoing system | Behavioural, state machine | **Kept** | Two systems must agree; the rule is costly to rediscover and is read by both sides | | Which parts exist and their multiplicities | Structural, class | **Sketch, kept only for the confusing corner** | Mostly recoverable by reading; one part of it genuinely is not | | The nightly roll-up path | Behavioural, interaction | **Sketch** | Settles one conversation, then done | | Full goal inventory | Behavioural, use case | **Once, then not maintained** | Useful to find gaps at the start; a moving target afterwards | | Composite structure, timing, packages | Either | **Not drawn** | No open question in this team requires them | That team uses three families of a taxonomy with ten-plus entries, keeps one diagram, and can say in a sentence why each line reads the way it does. That is a healthy answer. A team that draws every family because the taxonomy has them, or none because modelling feels ceremonial, is answering the wrong question in either direction. ## The failure modes to name - **Modelling as a phase.** Deciding up front to produce a fixed set of diagram types before implementation starts, rather than drawing in response to open questions. - **Standardising the notation instead of the habit.** Mandating diagram types is cheap to write and buys nothing; the transferable habit is *phrase the question, then choose*. - **Never drawing at all.** The opposite over-correction, usually justified as pragmatism. It shows up as repeated hallway arguments over ordering that a five-minute sketch would have ended, and as invariants that only exist in one person's head. - **Confusing volume with rigour.** Ten diagrams do not describe a system better than three; they describe it in ten places that can disagree. The judgement an interviewer is listening for is that you buy modelling where ambiguity is concentrated and expensive, that you know a sketch is a legitimate finished product, and that you can defend a small number of kept models rather than defaulting to either extreme.
- What makes a lifecycle model worth keeping when a class-level sketch is not?Recoverability. What parts exist and how they relate can usually be recovered by reading, so a drawing of it saves minutes. Which transitions are forbidden is often not written down anywhere, is learned from incidents, and cannot be recovered by reading — so stating it once in a place both readers trust has a much higher return.
- A team says modelling is ceremonial and draws nothing at all. What does that cost them?It shows up as repeated arguments about ordering that a five-minute sketch would have ended, and as invariants that live only in one person's head and leave when they do. The corrective is not a modelling standard but the habit of drawing in the moment of disagreement and then throwing the drawing away.
- Why is mandating a fixed set of diagram types a weak lever?Because it standardises output rather than judgement. Teams satisfy the mandate with diagrams nobody asked for, the drawings are read once at review, and the recurring cost lands anyway. The transferable habit is phrase the open question first, then choose the family that answers it — which is coachable and produces fewer, better-aimed diagrams.
Most diagrams are like the back of an envelope during a conversation — the value was in the talking, and keeping the envelope buys nothing.
saying these in an interview costs you the question
- Says a serious team should use every diagram type
- Treats all modelling as ceremony to be avoided
- Cannot name a diagram they would deliberately not draw
- Mistakes volume of diagrams for design rigour
- Wants a modelling phase before implementation begins
- Thinks every diagram drawn has to be kept afterwards