6 ms·

> Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. This is very untrue. Many moons ago my company changed

> Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. This is very untrue. Many moons ago my company changed its name, and we still have the old name lingering around in stupid places. There are e.g. several third-party services which simply won't let us change the name and carry our data forward, or where proper migration would take eng-months. I guess you could say we're "not determined enough" (pause development! take the data loss!) but it just doesn't make business sense to pursue it.

bmitc 4y ago
We're talking about software service and component names. Not names in general or company names.
- lodovic 4y ago
  In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.
  - bmitc 4y ago
    I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.
    - Spivak 4y ago
      By doing this your names aren't in 1NF and you're making it harder than needed to do updates. If your names are cute/unique then changing, expanding, or reducing service responsibilities just means updating the single document that says what Dreki does.
- ddulaney 4y ago
  Software names and component names can be really hard to change though, especially because those names tend to leak into the public API. When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++ or Java or other namespace, executable file name for scripting, etc.). So yes, software service and component names are hard to change when customers start relying on them.
  - bmitc 4y ago
    So why not rename versions to cutesy names then? Function names? Argument names? That way, you never have to rename anything and can just change the behavior.
    - ddulaney 4y ago
      Sorry for the wall of text. I found your question super valuable for crystallizing my thoughts. TL;DR: Abstract names are good when your scope is poorly defined and hopefully your functions aren't like that. If they are, maybe consider abstract names for them. The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want. Why not use abstract names at smaller scales? I can come up with a couple of reasons: First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;). Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply. Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name. Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.
- superb-owl 4y ago
  It's the same principle IMO. The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.
  - bmitc 4y ago
    See my other comment in another reply, but are you suggesting that it's better for something to keep the same name while also changing its behavior and purpose? It doesn't make any sense.
  - surement 4y ago
    > The name gets repeated in so many places if it's important. like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have if it had a descriptive name then other functionality would've been put in their own module
pjc50 4y ago
There are quite a few of these. Jenkins has "Hudson" in its internal namespaces. Various Microsoft products have their old names in classes. Once a name is used externally, it doesn't matter how organized you are, there are uses outwith your control.
- giraffe_lady 4y ago
  NSeverything in apple APIs is another good one I think.
  - whatshisface 4y ago
    Now it stands for NameSpace.
whoisthemachine 4y ago
I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather focus on the function when trying to name something. It will do you no good if something is called `MyCompanyCart` when it instead could have just been called `Cart`. Most of all, don't include the name of the company in the codebase, especially as variable names, and double especially in data definitions.
- williamcotton 4y ago
  The problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market. The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”. It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier to find and talk about than K297400!
  - pfix 4y ago
    Isn't that why namespaces were invented? You put those in the namespace `AdServer: { Server, Renderer, Storage }`
    - williamcotton 4y ago
      Sure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?
      - whoisthemachine 4y ago
        Namespacing can exist in more ways than just in code. Surely you could have your server, renderer, and storage components in one repository under the Ads product: Ads/ Server Renderer Storage
Spivak 4y ago
Another example is Discord. In the beginning Discord servers were called Guilds and that's still their name in all their documentation and APIs. So it's more than company names.
- 71bw 4y ago
  Discord is a... indecent woman to work with, if you want to build a bot once so that it works for any longer period of time... you need to wake up, because that's sadly not how it works.
  - Spivak 4y ago
    I have no idea what you're talking about but Discord has got to be one of the most pleasant bot development experiences that exists. Their shit is really well architected and their API handles so much lifting for you. I get that some people were burned by the switch from "free-for-all text bots" to structured bots with OAuth but the new way is so so so much better.
yokoprime 4y ago
Vermeer Technologies still linger in Microsoft 365. I think they were acquired in the 90s and their product became Frontpage, which became SharePoint. A bunch of critical services lives in _vti_bin
gnull 4y ago
Agreed. People may not be determined enough and that's fine because not every cause is worth determination. I say this each time someone wants to rename something for social justice reasons. Renaming is a lot of hussle, and if you decide to go for it you better know what exactly it is that you're buying with it.

bmitc 4y ago

We're talking about software service and component names. Not names in general or company names.

lodovic 4y ago
In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.
- bmitc 4y ago
  I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.
  - Spivak 4y ago
    By doing this your names aren't in 1NF and you're making it harder than needed to do updates. If your names are cute/unique then changing, expanding, or reducing service responsibilities just means updating the single document that says what Dreki does.
ddulaney 4y ago
Software names and component names can be really hard to change though, especially because those names tend to leak into the public API. When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++ or Java or other namespace, executable file name for scripting, etc.). So yes, software service and component names are hard to change when customers start relying on them.
- bmitc 4y ago
  So why not rename versions to cutesy names then? Function names? Argument names? That way, you never have to rename anything and can just change the behavior.
  - ddulaney 4y ago
    Sorry for the wall of text. I found your question super valuable for crystallizing my thoughts. TL;DR: Abstract names are good when your scope is poorly defined and hopefully your functions aren't like that. If they are, maybe consider abstract names for them. The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want. Why not use abstract names at smaller scales? I can come up with a couple of reasons: First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;). Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply. Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name. Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.
superb-owl 4y ago
It's the same principle IMO. The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.
- bmitc 4y ago
  See my other comment in another reply, but are you suggesting that it's better for something to keep the same name while also changing its behavior and purpose? It doesn't make any sense.
- surement 4y ago
  > The name gets repeated in so many places if it's important. like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have if it had a descriptive name then other functionality would've been put in their own module

pjc50 4y ago

There are quite a few of these. Jenkins has "Hudson" in its internal namespaces. Various Microsoft products have their old names in classes. Once a name is used externally, it doesn't matter how organized you are, there are uses outwith your control.

giraffe_lady 4y ago
NSeverything in apple APIs is another good one I think.
- whatshisface 4y ago
  Now it stands for NameSpace.

whoisthemachine 4y ago

I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather focus on the function when trying to name something. It will do you no good if something is called `MyCompanyCart` when it instead could have just been called `Cart`. Most of all, don't include the name of the company in the codebase, especially as variable names, and double especially in data definitions.

williamcotton 4y ago
The problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market. The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”. It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier to find and talk about than K297400!
- pfix 4y ago
  Isn't that why namespaces were invented? You put those in the namespace `AdServer: { Server, Renderer, Storage }`
  - williamcotton 4y ago
    Sure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?
    - whoisthemachine 4y ago
      Namespacing can exist in more ways than just in code. Surely you could have your server, renderer, and storage components in one repository under the Ads product: Ads/ Server Renderer Storage

Spivak 4y ago

Another example is Discord. In the beginning Discord servers were called Guilds and that's still their name in all their documentation and APIs. So it's more than company names.

71bw 4y ago
Discord is a... indecent woman to work with, if you want to build a bot once so that it works for any longer period of time... you need to wake up, because that's sadly not how it works.
- Spivak 4y ago
  I have no idea what you're talking about but Discord has got to be one of the most pleasant bot development experiences that exists. Their shit is really well architected and their API handles so much lifting for you. I get that some people were burned by the switch from "free-for-all text bots" to structured bots with OAuth but the new way is so so so much better.

yokoprime 4y ago

Vermeer Technologies still linger in Microsoft 365. I think they were acquired in the 90s and their product became Frontpage, which became SharePoint. A bunch of critical services lives in _vti_bin

gnull 4y ago

Agreed. People may not be determined enough and that's fine because not every cause is worth determination. I say this each time someone wants to rename something for social justice reasons. Renaming is a lot of hussle, and if you decide to go for it you better know what exactly it is that you're buying with it.