I don't care what it is called, tell me what it is!

With nearly three decades of experience writing software, I can tell you that I no longer worry about the names of things nearly so much as I used to.  In my early days, we'd put the names into the product, and almost like clockwork, marketing would change the product name weeks or even days before release of the final (planned) build to QA.  Inevitably, search and replace would fail producing a nonsense phrase, and/or someone would report a bug about bad text wrapping somewhere, or even worse, nobody would spot the problem caused by the name change.

As I grew more experienced, we'd slug the name AND reserve more than the expected amount of space for it in the UI, and design for the inevitable change (or two).  And I'd refuse to put the current name of the product in until Marketing had a) signed off on the product name, and b) spent their own money producing marketing literature using it.  In which case, I felt safe enough to go forward with it.

These days, I'm much more concerned with understanding what it is, rather than what you call it.  I know how to describe something using numerous different names.  There are names that engineers recognize, and other names for architects, and yet others names for marketers and C-levels.  The key is not in naming, but in describing what it is in a way that your audience will understand it.

Case in point: Archetype, Template and Detailed Clinical Model.  Explain the difference between these.  The way I do it for a CEO is fairly straightforward.  These are all essentially the same thing.  The way I do it for practitioners of these black arts is much different.  It's like explaining the difference between cancer, melanoma and tumor to people with various levels of medical understanding.

Yes, the fine details matter.  But only to SOME audiences.

-- Keith