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.

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.