As an example of the author's idea in practice, imagine a car, where every part in the car had a cute name, and every car in the world had different cute names.

As an example of the author's idea in practice, imagine a car, where every part in the car had a cute name, and every car in the world had different cute names. Now imagine being a mechanic. Or going to work for a new car company. Or just being in analytics and trying to understand how to work with the product. Or being a customer trying to understand how your new car works. A part named after its technical role/purpose shouldn't need to be renamed. If its purpose has changed, you have a different service. Without renaming it, are you talking about OLD cutename, or NEW cutename? Or NEW-NEW cutename? Major version numbers help here, for any kind of name. Sometimes names are too generic, like "web", or "auth". New services can be named something more specific to be more distinct. Things named after parts of the organization always get renamed, so always avoid that. No team names, org names, business specific monikers, etc. And the whole idea of code-as-docs is that your code is descriptive enough that you don't need to pepper tons of comments through the code to understand what it's doing. The same can be applied to architectural components like service and server names. But you know what? If you really feel that strongly about it? Go ahead and use cute names. For your service. The rest of us will be using boring names, and yours will be the odd service out, because you don't get to tell the entire team/business what to do by fiat (unless you're a horrible micromanager).