A long-standing debate between me and a peer at work has been how we should name services. His position was always that services should be named something descriptive, so that you can infer from the name what it does. My position is that the name should definitely not be descriptive, but should be something cute and wholly disconnected from the purpose. And I think this applies more broadly to projects and companies, too.

The appeal of a descriptive name is clear and immediate. On reading the name of the service, you know what it does. broadcast-service probably broadcasts something, machine-learning-worker is probably a worker that does something, like trains a model. As long as this is a true description, the name works. For now.

Trouble is, names are hard to change¹. Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization. Not to mention all the actual code changes you have to make to actually change a name of a service. It's probably mentioned in other services, it's in your own module imports, and it's in your infrastructure-as-code. And then it's also littered throughout the internal documentation that you have. (That you have, right? And it's kept up to date?)

The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. Your service which started with a nice, tidy set of responsibilities may start to shift over time. And then you're faced with a choice: keep the old descriptive-but-now-wrong name, or put in all the effort to change it.

I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name.

It's impossible to predict with certainty how your software's requirements will evolve over time. And if you don't know what your software will need to do later, you don't know what the ideal factoring will be then, let alone now. It will almost certainly change over time. If you pick a descriptive name, then that's going to be a misleading name when those responsibilities change.

And then the cherry on top, the final nail in the coffin of descriptive names: They're just too hard to say and remember, and they're no fun. I don't want my services or projects to sound like a law firm ("Ingest, Processing, & Storage LLP"). A descriptive name will be wordy, or boring, or both. It won't be memorable, and it won't be fun. On the other hand, something that's cute will be far more memorable and much easier to say.

The world is boring enough as is. Let's add more whimsy and cuteness through our service and project names.