The author makes some good points, names rot just like bits. I think initialisms are sometimes in a funny place. Their real meaning can become obsolete over time, while the initialism remains relevant.
LLVM used to mean Low-Level Virtual Machine, nowadays it’s a compiler infra ecosystem. HTTP is everywhere, but we do a lot more things than transfer and manipulate hypertext on the web.
My current job does this, and I don’t have a word for just how confusing it make things. It would be a very bad word though. Something evoking religious imagery of eternal suffering, perhaps a reference to Sisyphus.
BUT - and this pains me to say - it’s also not wrong at all. These points are completely valid. Semantics change over time. Names become obsolete. Worse, having to name two very similar things that only differ by a tiny semantic bit leads to really terrible names that don’t make the situation any better.
Also, let’s say you could even successfully rename things from a technical perspective, there’s the human perspective. Everyone is going to use the old name for 2 years anyway. Humans don’t have the ability to erase context overnight.
Basically, against my desire, I firmly believe that at its limit, naming is futile. We shouldn’t purposefully obfuscate things with bad names, but there is no hope for good names either. Behavioral semantics is too information-dense to communicate with a few characters. It needs more bits of info to successfully be transmitted with low entropy.
My approach is this: when you name a component like, SomethingSomething, and you’re explaining it to someone and they’re like “SomethingSomething?” And you respond, “You know, the X-doing service”.
Then you should just rename it to “X-doing-service”. No matter how stupid or wrong it sounds.
Three years ago I made the mistake of introducing the new search engine as Elasticsearch and I’ve been correcting people ever since that it’s just the database.
I use this pattern for branch names. It’s convenient. Rarely it discovers some offensive pair of words. Most often though it results in names that are completely useless and on a number of occasions I’ve struggled to find the right branch for something.
Certainly better branch name than enforced ticketing system ID. You really think I’m gonna bother memorizing a string of integers or that I want to open & search JIRA just to find the ID?
I’ve recently started doing that with my personal projects, using some random generator page I found. It basically spits out “whimsical adjective” “animal or funny object” word pairs. I cycle through them until I find one that sort of kind of matches the project. Examples:
glowing lamp: my effort to keep a restructured text engineering log book to make public
fancy hat: building an FOC-based brushless motor controller. Tenuous connection… a ball cap with a propellor on it is a fancy hat. The BLDC will be spinning a propellor on it.
lost elf: ESP32-based temperature sensor that’s going to live in the crawl space over the winter to make sure the heat tape on the water line is working
I’ve worked with cryptic names, and with descriptive names. Even if the descriptive names were no longer true to the complete scope of a service, they were easier to navigate. We don’t need to abandon descriptive names just because they aren’t perfect.
The names should be hints about what the system does, but not direct descriptions because of the name drift problem. Mercury can start as the messenger service of the gods and then drift into also managing s3 buckets or whatever.
Roughly 90% of the abstractly named services I’ve dealt with have been allusions to either Greek mythology or Lord of the Rings. The remaining ~10% were called George, Frank, or Henrietta.
There’s just one class in one of my current projects that is from Greek mythology (all the rest are vaguely descriptive), and it annoys me whenever I see it.
Roughly 90% of the abstractly named services I’ve dealt with have been allusions to either Greek mythology or Lord of the Rings. The remaining ~10% were called George, Frank, or Henrietta.
There’s just one class in one of my current projects that is from Greek mythology (all the rest are vaguely descriptive), and it annoys me whenever I see it.
I work in a big place. The names (brand) of services are abstract, but the actual implementations usually are not, so you have a sense of what the software architecture is by looking at a call stack at least.
This is a good thing. You only have to learn Greek mythology and LOTR to have an idea what a thing is. There’s no hope for George, Frank, and Henrietta, though. Can be anything.
I mean if your company is using so many different systems that you (the person who is ostensibly responsible for their uptime at some point) cannot remember what each one does there is something wrong.
You don’t need to remember the exact config or the arguments to get a debug log or any of that - but if you can’t remember the names of the tools you use and are actively monitoring, there is something very wrong.
Or renamed, which means the org should have a policy and process for turning down an old service and migrating to a new one, which is common during scaling.
As a Clojurist, I strongly disagree. Clojure libraries are simple, have one purpose, and then they’re completed and don’t balloon into gigantic frameworks with scope creep and an eventually mismatching name. This article just points out a flaw in modern programming approaches and not really a universal truth. Aim for composability and then you can name each level of abstraction a new thing if you need to.
Oh, yeah, sorry, forgot to clarify that I meant that Clojure libraries are unlikely to ever end up bloating to the point of names mismatching, but unfortunately, Clojure has a ton of silly named libraries and projects. Really, you can do this with any language where you can write nicely atomic, composable, purely functional libraries, that rely on common data structures for their interfaces. Like, JavaScript and Ruby mostly come to mind. But culturally, it’s popular to find witty names for projects nowadays, so it is what it is…
There’s a big difference between libraries and services though. For one, libraries usually compose much better than services, and second, the purpose of a single library is usually fixed in scope, whereas a service tends to grow with a company’s goals etc.
But also, there’s no reason to not name subcomponents either, especially in log messages. “Shelob has broken again” is so little descriptive than saying “Shelob’s crawler halted because we set the outbound firewall rules too strict again”.
I would like things to have many names, like I do. Especially software components. That way if I need to get very specific I can use the full name, and if I don’t because everybody got local context, I can use a nickname. I guess renaming things is about as complicated with software components as it is for people and landmarks but I have a hard time understanding why.
Names matter only if people understand what you’re referring to, they don’t necessarily have to explain what they refer to. But it’s kinda nice when you can get that out of the name. Real world examples would include places of business names after the person running it. “Bob and Son’s Plumbing” is pretty good. Would be more confusing if it did not contain “Plumbing”. Locals probably refer to that outfit as “Bob and Son’s”, “Bob’s”, or maybe even “the plumber” if the town is really small. Conversely you could have something like idk, the “Bob and Son’s Message Queue Service”. Nobody would care unless you started having many message queues, I guess? Idk.
Naming is weird and complicated and contextual, and I believe efforts to magic away the complexity by making them just opaque strings might be unwise.
Now, if a name is going to be easily changeable forever, please do make it descriptive.
I’ll go a step further: Don’t make a whimsical and cryptic name unless it can’t be renamed later and you intend for it to last enough years and major versions to grow beyond its original scope in unknowable ways.
I’ve gone both ways on this out of pragmatism, but I tend to prefer semi-whimsical to be honest. I prefer if the name has some loose association with what it’s doing as inspiration.
To compare the two:
I wrote a database migration runner called “Mallard” [1]
Mallard itself depends on a library imaginatively called “Koalephant Shell Script Library” [2]
The second is much more obvious what it does. But it’s so verbose it invariably ends up shortened to KSSL, which is back to being meaningless, and isn’t even pronounceable.
My approach going forward is definitely the semi-whimsical route, generally using elements from nature.
1: from the readme: Because a Mallard is a type of Duck that migrates.
2: Koalephant is the name of my consulting business.
Heh, my reaction to that explanation was “what? mallards don’t migrate!” because you can see them around here in all seasons. But it seems that they do migrate in North America but much less so in Britain, because of our milder climate.
The ACME client dehydrated refers to a Loony Tunes roadrunner / Wile E. Coyote prop labelled “ACME dehydrated boulders (just add water)”. Boulder is the name of the Let’s Encrypt CA software. (I don’t know if that name is also a Loony Tunes reference.)
In the early 2000s when at-office servers were a thing, and Tolkien was a big thing, I named two new testing servers Tuor and Huor. Due to the international vibe and lax pronounciation, referring to “huor” got considered too funny and the names got changed. Oddly enough I have no idea what the new namws were.
Medium has always handled sites with their own domains with this crazy redirect path. I don’t know why but I suspect it’s so they can cookie you on their main domain before you read on the custom domain.
No they shouldn’t. 5 years from now it’s going to cost a fortune to rename all that stuff when somebody who wears a tie notices one of your “whimsical” names, or the term you used for some foundational system referenced everywhere is now “problematic” on the social media platform de jour.
If you don’t want to use bland AbstractCorpoBollocksFactory names, just pick words off an existing list like local flora, the periodic table, subspecies of Amazonian frogs, something like that. Even that might bite you in the end, but trying to be clever and making cultural references always will.
Please, no, unless there are only going to be a few components, and you can stick to distinct names (carbon vs. sulfur). Too many of the more newly discovered elements end in the suffix -ium, which makes them less distinct from each other.
There’s a whole bunch more molecules though…
subspecies of Amazonian frogs
You might be surprised how many species names are from popular culture (biologists are people too).
The author makes some good points, names rot just like bits. I think initialisms are sometimes in a funny place. Their real meaning can become obsolete over time, while the initialism remains relevant.
LLVM used to mean Low-Level Virtual Machine, nowadays it’s a compiler infra ecosystem. HTTP is everywhere, but we do a lot more things than transfer and manipulate hypertext on the web.
Me: It’s called the Hypertext Transfer Protocol
Them: Oh, so it transfers hypertext?
Me: …I mean, sometimes.
My current job does this, and I don’t have a word for just how confusing it make things. It would be a very bad word though. Something evoking religious imagery of eternal suffering, perhaps a reference to Sisyphus.
BUT - and this pains me to say - it’s also not wrong at all. These points are completely valid. Semantics change over time. Names become obsolete. Worse, having to name two very similar things that only differ by a tiny semantic bit leads to really terrible names that don’t make the situation any better.
Also, let’s say you could even successfully rename things from a technical perspective, there’s the human perspective. Everyone is going to use the old name for 2 years anyway. Humans don’t have the ability to erase context overnight.
Basically, against my desire, I firmly believe that at its limit, naming is futile. We shouldn’t purposefully obfuscate things with bad names, but there is no hope for good names either. Behavioral semantics is too information-dense to communicate with a few characters. It needs more bits of info to successfully be transmitted with low entropy.
My approach is this: when you name a component like, SomethingSomething, and you’re explaining it to someone and they’re like “SomethingSomething?” And you respond, “You know, the X-doing service”.
Then you should just rename it to “X-doing-service”. No matter how stupid or wrong it sounds.
And what do you do when the service takes on or changes responsibility? I.e. when “X-doing-service” is no longer accurate.
Then you make a new service. (Even if just by forking.)
Three years ago I made the mistake of introducing the new search engine as Elasticsearch and I’ve been correcting people ever since that it’s just the database.
ever deploy something on heroku? You get two random names like “dark-resonance” or “sparkling-star”. There you go. Always just take two random words.
That’s too flippant for my personal taste.
I use this pattern for branch names. It’s convenient. Rarely it discovers some offensive pair of words. Most often though it results in names that are completely useless and on a number of occasions I’ve struggled to find the right branch for something.
Certainly better branch name than enforced ticketing system ID. You really think I’m gonna bother memorizing a string of integers or that I want to open & search JIRA just to find the ID?
I’ve recently started doing that with my personal projects, using some random generator page I found. It basically spits out “whimsical adjective” “animal or funny object” word pairs. I cycle through them until I find one that sort of kind of matches the project. Examples:
glowing lamp: my effort to keep a restructured text engineering log book to make public
fancy hat: building an FOC-based brushless motor controller. Tenuous connection… a ball cap with a propellor on it is a fancy hat. The BLDC will be spinning a propellor on it.
lost elf: ESP32-based temperature sensor that’s going to live in the crawl space over the winter to make sure the heat tape on the water line is working
It’s a parody, but taken to its logical extreme this choice leads to meetings like https://youtu.be/y8OnoxKotPQ
i love this video and the new one AI Girlfriend https://www.youtube.com/watch?v=KiPQdVC5RHU
I’ve worked with cryptic names, and with descriptive names. Even if the descriptive names were no longer true to the complete scope of a service, they were easier to navigate. We don’t need to abandon descriptive names just because they aren’t perfect.
Yeah, what can be better than Pagerduty alert: service poopenfarten cannot connect to GandolNoMana.
The names should be hints about what the system does, but not direct descriptions because of the name drift problem. Mercury can start as the messenger service of the gods and then drift into also managing s3 buckets or whatever.
Roughly 90% of the abstractly named services I’ve dealt with have been allusions to either Greek mythology or Lord of the Rings. The remaining ~10% were called George, Frank, or Henrietta.
There’s just one class in one of my current projects that is from Greek mythology (all the rest are vaguely descriptive), and it annoys me whenever I see it.
I think that would annoy me so very much.
I work in a big place. The names (brand) of services are abstract, but the actual implementations usually are not, so you have a sense of what the software architecture is by looking at a call stack at least.
This is a good thing. You only have to learn Greek mythology and LOTR to have an idea what a thing is. There’s no hope for George, Frank, and Henrietta, though. Can be anything.
I mean if your company is using so many different systems that you (the person who is ostensibly responsible for their uptime at some point) cannot remember what each one does there is something wrong.
You don’t need to remember the exact config or the arguments to get a debug log or any of that - but if you can’t remember the names of the tools you use and are actively monitoring, there is something very wrong.
I agree with that, even if it can makes onboarding “fun”… :)
Tangentially, when software escapes the scope of its original name, it is also an indicator that it could be split up somehow.
Or renamed, which means the org should have a policy and process for turning down an old service and migrating to a new one, which is common during scaling.
As a Clojurist, I strongly disagree. Clojure libraries are simple, have one purpose, and then they’re completed and don’t balloon into gigantic frameworks with scope creep and an eventually mismatching name. This article just points out a flaw in modern programming approaches and not really a universal truth. Aim for composability and then you can name each level of abstraction a new thing if you need to.
“Leiningen.”
Makes perfect sense, it’s for coping with the situation when you have far far far far far too many ant invocations to deal with.
Oh, yeah, sorry, forgot to clarify that I meant that Clojure libraries are unlikely to ever end up bloating to the point of names mismatching, but unfortunately, Clojure has a ton of silly named libraries and projects. Really, you can do this with any language where you can write nicely atomic, composable, purely functional libraries, that rely on common data structures for their interfaces. Like, JavaScript and Ruby mostly come to mind. But culturally, it’s popular to find witty names for projects nowadays, so it is what it is…
There’s a big difference between libraries and services though. For one, libraries usually compose much better than services, and second, the purpose of a single library is usually fixed in scope, whereas a service tends to grow with a company’s goals etc.
But also, there’s no reason to not name subcomponents either, especially in log messages. “Shelob has broken again” is so little descriptive than saying “Shelob’s crawler halted because we set the outbound firewall rules too strict again”.
I would like things to have many names, like I do. Especially software components. That way if I need to get very specific I can use the full name, and if I don’t because everybody got local context, I can use a nickname. I guess renaming things is about as complicated with software components as it is for people and landmarks but I have a hard time understanding why.
Names matter only if people understand what you’re referring to, they don’t necessarily have to explain what they refer to. But it’s kinda nice when you can get that out of the name. Real world examples would include places of business names after the person running it. “Bob and Son’s Plumbing” is pretty good. Would be more confusing if it did not contain “Plumbing”. Locals probably refer to that outfit as “Bob and Son’s”, “Bob’s”, or maybe even “the plumber” if the town is really small. Conversely you could have something like idk, the “Bob and Son’s Message Queue Service”. Nobody would care unless you started having many message queues, I guess? Idk.
Naming is weird and complicated and contextual, and I believe efforts to magic away the complexity by making them just opaque strings might be unwise.
Software needs middle names so I can properly scold it.
I’ll go a step further: Don’t make a whimsical and cryptic name unless it can’t be renamed later and you intend for it to last enough years and major versions to grow beyond its original scope in unknowable ways.
I’ve gone both ways on this out of pragmatism, but I tend to prefer semi-whimsical to be honest. I prefer if the name has some loose association with what it’s doing as inspiration.
To compare the two:
I wrote a database migration runner called “Mallard” [1]
Mallard itself depends on a library imaginatively called “Koalephant Shell Script Library” [2]
The second is much more obvious what it does. But it’s so verbose it invariably ends up shortened to KSSL, which is back to being meaningless, and isn’t even pronounceable.
My approach going forward is definitely the semi-whimsical route, generally using elements from nature.
1: from the readme: Because a Mallard is a type of Duck that migrates.
2: Koalephant is the name of my consulting business.
Heh, my reaction to that explanation was “what? mallards don’t migrate!” because you can see them around here in all seasons. But it seems that they do migrate in North America but much less so in Britain, because of our milder climate.
What program has the deepest reference that makes complete sense when it’s explained?
The ACME client
dehydratedrefers to a Loony Tunes roadrunner / Wile E. Coyote prop labelled “ACME dehydrated boulders (just add water)”. Boulder is the name of the Let’s Encrypt CA software. (I don’t know if that name is also a Loony Tunes reference.)Oooohh that’s a great one
vim
See also: https://www.vice.com/en/article/4avn8q/computer-man-unusual-names-filipino
In the early 2000s when at-office servers were a thing, and Tolkien was a big thing, I named two new testing servers Tuor and Huor. Due to the international vibe and lax pronounciation, referring to “huor” got considered too funny and the names got changed. Oddly enough I have no idea what the new namws were.
https://www.wired.com/2015/11/null/
Any one else getting errors with Skip Redirect add-on installed? Why are we going thru medium.com?
Medium has always handled sites with their own domains with this crazy redirect path. I don’t know why but I suspect it’s so they can cookie you on their main domain before you read on the custom domain.
Well, I never got to read it because the writer chose Medium over hosting a blog themselves
I recommend the https://scribe.rip/ front-end, which can proxy any Medium-powered article. https://scribe.rip/software-component-names-should-be-whimsical-and-cryptic-ca260b013de0 loads fine for me even with cookies cleared and JavaScript disabled.
No they shouldn’t. 5 years from now it’s going to cost a fortune to rename all that stuff when somebody who wears a tie notices one of your “whimsical” names, or the term you used for some foundational system referenced everywhere is now “problematic” on the social media platform de jour.
If you don’t want to use bland
AbstractCorpoBollocksFactorynames, just pick words off an existing list like local flora, the periodic table, subspecies of Amazonian frogs, something like that. Even that might bite you in the end, but trying to be clever and making cultural references always will.I don’t foresee problems with that scheme.
Please, no, unless there are only going to be a few components, and you can stick to distinct names (carbon vs. sulfur). Too many of the more newly discovered elements end in the suffix -ium, which makes them less distinct from each other.
There’s a whole bunch more molecules though…
You might be surprised how many species names are from popular culture (biologists are people too).
https://en.wikipedia.org/wiki/Strigiphilus_garylarsoni
All of these strike me as in line with what the article is suggesting. Did I misunderstand something?