3 ms·

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 peo

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...")

gabereiser 4y ago
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.
- deleted 4y ago
  [deleted]
sebastos 4y ago
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 :)
- kuramitropolis 4y ago
  >MANGA company I'm gonna close the Internet for today because you, sir, just won it

gabereiser 4y ago

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.

deleted 4y ago
[deleted]

sebastos 4y ago

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 :)

kuramitropolis 4y ago
>MANGA company I'm gonna close the Internet for today because you, sir, just won it