> The naming grew as our understanding of the function grew.

Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and useless as Cholesterol's "true" name.

> Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol.

Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service. So the name "TextCheckerTranslator" is partially irrelevant to both. And what happens when you add a third function to it? It now can also do OCR. So now your CRM program, which only cares about the "checker" part, needs to be re-compiled or have its config changed because it now needs to call the "TextCheckerTranslatorOCR" service instead. Every downstream service has to be changed because of changes that have nothing to do with them! Just call it "Wordsmith".

> More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services.

Our understanding of chemicals changes, just like our understanding of which services should do what (and what that means) changes. But either way, if services are more likely to change, then all the more reason to use artificial names for them (rather than trying to encode all their purposes).

> Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson.

Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words. I agree the word should not be completely divorced from its use. SamuelLJackson would be a good name for a service which takes boring text and liberally inserts creative swear words into it.

> Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time.

We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes. The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.