4 ms·

You're optimizing for the wrong things and working with an artificially limited set of constraints. The rule of thumb is that we spend 10x the amount of time r

You're optimizing for the wrong things and working with an artificially limited set of constraints. The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day. Further, you're introducing unnecessary, artificial constraints. If you need to add new responsibilities to a service that don't fit with in it's existing scope - the correct answer is to make a new service. Granted, some times we don't have time for either a rename or a new service and we have to duct tape the functionality wherever we can. This is called techdebt. It should be documented, tracked, and paid down at a later date... By renaming the service or refactoring out a new one. Attaching arbitrary functionality on to cutely named services that don't have logical coherence is not future proofing. It's really bad software design.

Hermitian909 4y ago
This is good advice in the small, but I think the author is correct for larger services. I can't tell you how many times someone insisted on a name that was "universal such and such" which, uh, turned out not to be universal. More concretely, this is good advice for services that you expect many teams to hook into, and not great advice for services that you think should not expand 1-3 teams ever.
- dbingham 4y ago
  I think the problem you're speaking to has more to do with attempts at "universal" design. Which actually runs counter to the principal that services should have a limited, clearly defined set of responsibilities.
ilyt 4y ago
> The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day. That is for name of variable. Changing a name of whole application can be royal PITA all over the stack, if the "one time change" is "scour every documentation ever produced and change the name there too so people won't get confused. And not just docs, put the name of service as query in Grafana ? Gotta go around dashboards changing that too
grahar64 4y ago
If you work at a company for more than a week you will get used to the names of services and what they do. But if the name of a service becomes a lie because of changing requirements, then it will be an actual hinderance to understanding a system.

Hermitian909 4y ago

This is good advice in the small, but I think the author is correct for larger services. I can't tell you how many times someone insisted on a name that was "universal such and such" which, uh, turned out not to be universal. More concretely, this is good advice for services that you expect many teams to hook into, and not great advice for services that you think should not expand 1-3 teams ever.

dbingham 4y ago
I think the problem you're speaking to has more to do with attempts at "universal" design. Which actually runs counter to the principal that services should have a limited, clearly defined set of responsibilities.

ilyt 4y ago

> The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day. That is for name of variable. Changing a name of whole application can be royal PITA all over the stack, if the "one time change" is "scour every documentation ever produced and change the name there too so people won't get confused. And not just docs, put the name of service as query in Grafana ? Gotta go around dashboards changing that too

grahar64 4y ago

If you work at a company for more than a week you will get used to the names of services and what they do. But if the name of a service becomes a lie because of changing requirements, then it will be an actual hinderance to understanding a system.