Everyone in the business calls it the fax queue, and nothing has been faxed since 2014. Do you keep that name in the code?

The word is doing a job that accuracy would not do better

The reason to use the business's own vocabulary is not respect for tradition. It is that a shared word lets two people who know different things point at the same object and be sure they have. When an operator says "it is stuck in the fax queue" and you know precisely which table, which job and which failure that describes, the word has succeeded completely, and the fact that it names a device nobody owns any more has cost nothing.

Rename it to manual_outbound_dispatch_queue on your own authority and you do not get one accurate vocabulary. You get two: yours in the repository and theirs in every conversation, ticket, handover and phone call, with a translation step in the middle that only you can perform. That is strictly worse than the fossil, because the fossil was at least shared. Fossil names are also excellent identifiers precisely because they are odd — nobody has ever confused "the fax queue" with anything else, whereas a tidy generic name collides with three other tidy generic names within a year.

So the default is to keep the word. What you must not keep is the assumption inside it.

Keep the label, model the concept

The dangerous part of a fossil is not the name; it is that the name asserts a mechanism, and the mechanism is what an engineer builds. If you take "fax queue" literally you get a channel-specific design: a fax number field, a fax retry policy, a status vocabulary borrowed from a fax gateway. What the business means is almost never that any more. It is usually something like "outbound items that cannot be sent automatically and need a person", which is a domain concept with a completely different shape and a channel as one of its attributes.

Establishing which of those you are looking at takes one question, asked of the queue rather than of a person: what is in it, right now, and what do the items have in common? Fossil names decay in a small number of recognisable ways, and the decay determines the design.

What the term picks out today	The fossil's real status	What you do
The same set of things, sent a different way	Harmless label, mechanism moved	Keep the word, drop the mechanism from the model
A superset — several channels, one manual step	The word now names a category	Keep the word for the category, model the members
A subset — one leftover case out of the original scope	A shrinking special case	Keep it, and ask what took over the rest
Two different things, depending on who says it	Not a fossil, an ambiguity	This one must be split before you build anything

The second row is the common case and the one that repays attention in an interview. A name that has quietly become a category is the cheapest available piece of domain insight, because the business has already done the generalisation and simply never renamed the box. Modelling it as the category, while continuing to call it the fax queue out loud, gives you a design that absorbs the next channel without a schema change and a vocabulary that needs no translation.

Where the fossil has to go

The default is not absolute, and a candidate who only argues for preservation has answered half the question. Four cases force a change.

The word is customer-facing. A term that works internally can be wrong, dated or embarrassing in a letter, a screen or an API a partner consumes, and the external name is a product decision rather than a modelling one. Internally it can survive unchanged.

The word has two meanings in use. That is not a fossil problem and preservation makes it worse, because the shared word is the defect. Split it, in the business's language, with both new terms attributed to the team that owns each.

The word collides with a defined term. Where a regulation, standard or contract defines a word precisely, the defined meaning wins in anything that can be read as a compliance artefact, and continuing to use the local sense in a report is how you end up explaining yourself to somebody who has the rulebook open.

The name encodes a constraint that is no longer true and is load-bearing in code. A column called fax_number holding email addresses is not a naming irritation; it is a place where the next engineer will apply a length limit, a format validation or a masking rule from the wrong domain. Names that lie about type or format cause defects, and those are worth migrating.

How to change vocabulary without decreeing it

If you conclude a term genuinely needs replacing, the mechanism is adoption rather than announcement. Introduce the new term next to the old one in artefacts the business already reads — the ticket title, the report heading, the runbook step — with the fossil in brackets after it, and use both in speech for a while. Ask the operations lead which word they would use, and take their answer even when it is uglier than yours. A term the business supplied propagates; a term engineering issued gets translated back on first contact.

Meanwhile, write down what the fossil meant. The single most useful line in a glossary is not the current definition but the history: this queue was named when items were faxed to brokers, it now covers anything requiring manual dispatch, and the word survives because everybody knows it. That sentence stops the next joiner from either building a fax integration or deleting a name they think is dead.