3 ms·
> 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 b
by jxf 4y ago
> 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.
I couldn't disagree more. This is exactly why you would want the name to be descriptive. If the thing that's supposed to be a notifications service suddenly also starts processing payroll, that's absolutely a friction point that should give people pause.
- sesteel 4y agoCould not agree more. Naming things for what they do encourages other behaviors like deprecation strategies and extension strategies that are non-disruptive to others. It makes people's lives easier if your work follows a level of rigor for naming. Products and companies can do many things under a single name, APIs should try to do the fewest number of things under a given name while fitting the concept as closely as possible.
- deleted 4y ago[deleted]