6 ms·

Codenames better recognize how design evolves over time. * If you split functionality out of one service, you end up with the old service's name implying it do

Codenames better recognize how design evolves over time. * If you split functionality out of one service, you end up with the old service's name implying it does both. E.g. you end up with a "auth" service that only handles cookie auth but not API keys. * If you expand the functionality of a service, you end up with a service's name not really clueing you in to what it does. E.g. "metadata" service that actually now includes smaller objects inlined into the database. * When you make a rewrite of a service, until the old one is fully retired you have two confusing names, and I hope you don't pick "new_auth" or something as that will be even more confusing after the first is turned down. Also codenames make searching for a particular component really easy. If you have to search for "auth" you will get all kinds of irrelevant results. If you search for "kazoo", you'll probably only get docs related to kazoo!

hourago 4y ago
> If you split functionality out of one service, you end up with the old service's name implying it does both. If you change what a class does you need to change the name, if you change what a method does you need to change the name, same for services. If it's too hard to change service names, that's your problem. > When you make a rewrite... Internal changes in a service must be transparent to consumers. If consumers are aware that you are doing internal work then you are doing something wrong. Codenames is the equivalent to call your variable John.
- dasil003 4y ago
  This completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.
  - hourago 4y ago
    > it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense. Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing. Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
    - afiori 4y ago
      It is easier to change a class name of a public library than the name of the public library. One is a breaking change, one is an official fork.
- stevebmark 4y ago
  I really like the comparison to variables/classes because it shows how poorly descriptive service names work. Services contain hundreds to millions of variables, classes, and lots of features, layers, etc. Comparing a service name to a variable shows why it's a poor idea to try to name your service descriptively, it contains so much and will change over time. And refactoring classes is easy, renaming services is much harder.
  - hourago 4y ago
    Maybe your services are just too big? I have seen classes with tens of thousands of lines, it was not good. Too big services are equally error prone and hard to work with.
- thaumasiotes 4y ago
  > Codenames is the equivalent to call your variable John. Imagine that you have a singleton object floating around your system, every single function written anywhere in the system must interact with that object heavily, and as a consequence everyone is familiar with what the object does and where it's defined. What problems do you think might arise if that object were named "John"?
  - hourago 4y ago
    That each new developer needs to learn that name. That it's difficult to understand what is that variable scope: does this new functionality fit in John or not. That most people know John but what happens with that other one that is rarely used named Jack and you find in in the code, and Anna and Maria? It would be the same for the computer running the code, the problem is for the developers trying to understand how to use it, how to expand it, etc.
    - thaumasiotes 4y ago
      Let me rephrase: what problems might arise that wouldn't be just as bad if a name other than John was picked? Everything you list is potentially a problem, but not a problem that got worse when we named the system John.
tsss 4y ago
It takes like 10 minutes to rename a service, less if you have better infrastructure automation and don't have to delete the deployment manually.
- phailhaus 4y ago
  That service name is in docs, channels, conversations, and in people's heads as well. Renaming services introduces a lot of confusion that extends much longer than the amount of time it takes to change the written references.
  - twic 4y ago
    When you split out part of a service, every previous reference to that service is now potentially wrong, because it may refer to the part of the service which have been split out. So explicitly breaking them is possibly more useful than preserving them. The crucial thing is to maintain a history of the names - precisely, a phylogeny of services.
- advisedwang 4y ago
  I guess it depends on the tech stack. Where I work it's very difficult, and I've never seen it happen. We have 10 year old obsolete names appear regularly.
twelfthnight 4y ago
Totally agree. Haven't heard someone describe this way of naming as "codenames", which I think gives the right impression that's is a placeholder name. It also suggests the service is a proper noun, instead using a name like "shipments" which is actually pretty confusing, since you often have to determine if you mean actual shipments or the service based on context. My experience is when we use "trivial" names folks just use abbreviations or other methods to disambiguate them anyway. For example, look at all the AWS services. Does anyone ever say "Elastic Compute Cloud" service? Come to think of it, that does seem like a fair compromise to have some formal-ish name for the service and just use a codename when referring to it.
- thaumasiotes 4y ago
  > Haven't heard someone describe this way of naming as "codenames", which I think gives the right impression that's is a placeholder name. "Codenames" are used for products for which the "name" is recognized as significant to the product. Thus, choosing the name is a project of its own -- and might take quite a bit of time -- while you might want to start work on the product before you finish picking the name. (Indeed, the work might inform the name!) But you have to be able to refer to the product, so you just give it some other name. When it's ready, you give it the "name". That's not what's happening here; what we have here is a big complicated system with a name. We don't expect to replace the name, but we do need to have it so that we can talk about the system.
arthurjj 4y ago
I think the "what a service does over time evolves" is probably the best argument I hear, but for me it comes down to a numbers game. Especially with microservices the majority of them don't evolve. So it becomes a question of which is preferable 1. 10 services named after Darkwing Duck characters 2. 8 services with descriptive names, and 2 with slightly wrong names I think most people would prefer 2

hourago 4y ago

> If you split functionality out of one service, you end up with the old service's name implying it does both. If you change what a class does you need to change the name, if you change what a method does you need to change the name, same for services. If it's too hard to change service names, that's your problem. > When you make a rewrite... Internal changes in a service must be transparent to consumers. If consumers are aware that you are doing internal work then you are doing something wrong. Codenames is the equivalent to call your variable John.

dasil003 4y ago
This completely fails to recognize the cost of change at different layers of abstraction. A service is an external facing entity that other teams need to interface with, it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names, let alone local variables.
- hourago 4y ago
  > it would cause an insane amount of churn to try to make changing service names as easy as changing internal class names It's easier to change your service name that a class name or method in a popular library used by millions of developers, and it is done because it's the only thing that makes sense. Can you imagine that your framework class to store data was named "Mercury" and the one to manage HTTP connections "Saturn"? Nobody would use such a thing. Good descriptive names help to use software properly. If you cannot change a service name because it's too costly, review your development process.
  - afiori 4y ago
    It is easier to change a class name of a public library than the name of the public library. One is a breaking change, one is an official fork.
stevebmark 4y ago
I really like the comparison to variables/classes because it shows how poorly descriptive service names work. Services contain hundreds to millions of variables, classes, and lots of features, layers, etc. Comparing a service name to a variable shows why it's a poor idea to try to name your service descriptively, it contains so much and will change over time. And refactoring classes is easy, renaming services is much harder.
- hourago 4y ago
  Maybe your services are just too big? I have seen classes with tens of thousands of lines, it was not good. Too big services are equally error prone and hard to work with.
thaumasiotes 4y ago
> Codenames is the equivalent to call your variable John. Imagine that you have a singleton object floating around your system, every single function written anywhere in the system must interact with that object heavily, and as a consequence everyone is familiar with what the object does and where it's defined. What problems do you think might arise if that object were named "John"?
- hourago 4y ago
  That each new developer needs to learn that name. That it's difficult to understand what is that variable scope: does this new functionality fit in John or not. That most people know John but what happens with that other one that is rarely used named Jack and you find in in the code, and Anna and Maria? It would be the same for the computer running the code, the problem is for the developers trying to understand how to use it, how to expand it, etc.
  - thaumasiotes 4y ago
    Let me rephrase: what problems might arise that wouldn't be just as bad if a name other than John was picked? Everything you list is potentially a problem, but not a problem that got worse when we named the system John.

tsss 4y ago

It takes like 10 minutes to rename a service, less if you have better infrastructure automation and don't have to delete the deployment manually.

phailhaus 4y ago
That service name is in docs, channels, conversations, and in people's heads as well. Renaming services introduces a lot of confusion that extends much longer than the amount of time it takes to change the written references.
- twic 4y ago
  When you split out part of a service, every previous reference to that service is now potentially wrong, because it may refer to the part of the service which have been split out. So explicitly breaking them is possibly more useful than preserving them. The crucial thing is to maintain a history of the names - precisely, a phylogeny of services.
advisedwang 4y ago
I guess it depends on the tech stack. Where I work it's very difficult, and I've never seen it happen. We have 10 year old obsolete names appear regularly.

twelfthnight 4y ago

Totally agree. Haven't heard someone describe this way of naming as "codenames", which I think gives the right impression that's is a placeholder name. It also suggests the service is a proper noun, instead using a name like "shipments" which is actually pretty confusing, since you often have to determine if you mean actual shipments or the service based on context. My experience is when we use "trivial" names folks just use abbreviations or other methods to disambiguate them anyway. For example, look at all the AWS services. Does anyone ever say "Elastic Compute Cloud" service? Come to think of it, that does seem like a fair compromise to have some formal-ish name for the service and just use a codename when referring to it.

thaumasiotes 4y ago
> Haven't heard someone describe this way of naming as "codenames", which I think gives the right impression that's is a placeholder name. "Codenames" are used for products for which the "name" is recognized as significant to the product. Thus, choosing the name is a project of its own -- and might take quite a bit of time -- while you might want to start work on the product before you finish picking the name. (Indeed, the work might inform the name!) But you have to be able to refer to the product, so you just give it some other name. When it's ready, you give it the "name". That's not what's happening here; what we have here is a big complicated system with a name. We don't expect to replace the name, but we do need to have it so that we can talk about the system.

arthurjj 4y ago

I think the "what a service does over time evolves" is probably the best argument I hear, but for me it comes down to a numbers game. Especially with microservices the majority of them don't evolve. So it becomes a question of which is preferable 1. 10 services named after Darkwing Duck characters 2. 8 services with descriptive names, and 2 with slightly wrong names I think most people would prefer 2