In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")

This is what I'm getting at though. If you work inside a MANGA company or something, then I imagine your life is probably dominated by navigating a huge byzantine ecosystem of services with uptime demands and tons of legacy code. Presumably there's lots of $$ riding on evolving those systems incrementally. In this frothing, roiling context where the only constant is change, I can see how it will often make sense to expand components beyond their original scope. Ergo, your services should be named whimsically. Fine.

But many software projects are. not. that. That's really all I'm getting at. This web service developer bubble annoys me because they never feel any onus to introduce themselves in their blogposts and caveat their opinionated recommendations with the context they're coming from. In my world of robotics, just making a random family of services with non-descript names is a bad idea. The services in the system should have roles, and if the temptation arises to add functionality beyond that role, it probably means you need to step back and do some thinking about why that happened.

Also: I know you were just making a rhetorical point, but notice that your example is still clearly some web service that we're assumed to be running :)

If you developed your services right. You’d have a notification service that does SMS,email,smokesignals…

It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator.

I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.

>Often times when people get creative with names, the meaning dies with them

That's fine though. Anything you work on will inevitably develop a personality in your mind beyond what the name literally means, so what's the difference if the name is something like GAS (generic-acronym-service) or Fuel (GAS > gasoline > fuel).

A persuasive dev at my last job tried to insist on non-acronym names for every new service, and 5 years on, I can still remember every proper name, but none of the acronyms. That, to me, is sign of a good name.

> The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming

I'd assume everyone here could at least agree that naming is hard. I don't think the article was attempting to explain how to name, but instead point out one potential pitfall when naming.

Yes. Naming is hard, but it’s easier when you aren’t using pop culture as names for things. Shelob service only makes sense if you are a Hobbit.

This, exactly. Seemingly misnamed services are a sign of architectural decay. That sign is useful if you pay attention to it. If it's embarrassing to explain to new hires, just fix it!