[tauwauwau]

I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go.

You can even name your products with generic descriptive names, if your company's name is unique enough, then that'll act as a namespace for product with generic names. Think of packages in Java, C#, we don't debate about that we have to use a cute name for a X.java or X.CS, because that problem has already been solved by namespaces.

Product name Excel and Office works for Microsoft because that "Microsoft" acts as namespace and "Microsoft Office" and "Microsoft Excel" are unique enough to be fully qualified names.

The ntietz entry is talking about using cute names for internal services, which is very bad idea. Please enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ

[m_mueller]

IMO there is a middle ground: larger & long living services that are internal only, and you have 1-2 handful of them. At my current employer I've started with greek gods whose background is related with the service we're building. E.g. Apollo = god of truth = data warehouse; Hermes = messenger god = messaging service for reporting, etc. It's quite successful in that these names are more quickly adopted and recognized by internal business users, compared to giving it a boring functional name. It also clearly outlines that they are part of a wider concept (new tech stack = greek gods, legacy marked for decommissioning = mostly everything else they hear).

[leokennis]

The issue is, if you create an internal tool that allows you to order printer paper for your departments printer you might name it "PaperSupplier": https://papersupplier.acme.com. If it doesn't work, just send a mail to [e-mail]!

And it works so well, the company now also wants employees to order staples and hole punchers through it.

What do you do now?

Are you going to rename the tool, change the address, change the e-mail?

Or is your company now going to have you order your staples through "https://papersupplier.acme.com"?

We all know it's the second.

My strategy would be to go for very generic names: even though it (initially) only allows you to order paper, name it "Internal Supply Portal" or something.

[tauwauwau]

You are right that function may evolve over time and name may not be completely accurate but it's still partially accurate opposed to being being completely inaccurate. In your example papersupplier, I would want to create a new site for staples or better create a new site for all categories of stationary instead of modifying the old one.

I like the idea of having a generic but still descriptive name.