Two other arguments for “cute” names, especially when you’re at a big company with many developers:
Searchability: If your company has hundreds of services, it may be hard to find the docs you want by searching for “load balancer”, but searching for “starfighter” will probably get the results you want.
Overlap and deprecation: Someday you may rewrite your load balancer in Rust! But both the old and new services will likely run in parallel for a while. As you migrate to the new service, it’s probably easier to distinguish “Starfighter” from “BurntMetal”, than “LoadBalancer” from “LoadBalancer2”.
And back in 2005, when we ran stuff on pets rather than cattle, our two firewall machines were called “Asbestos” and “Halon”, which I thought was rather cute and descriptive at the same time.
Searchability: If your company has hundreds of services, it may be hard to find the docs you want by searching for “load balancer”, but searching for “starfighter” will probably get the results you want.
I just know there are people out there reading this and thinking this is some first world problem that is surely not worth misnaming products over, so please allow me to one-up this just to further drive how useful it is and tl;dr how furiously I’m nodding when reading it.
If you’ve ever used Sharepoint, you probably know that its search function was atrocious. (Probably still is, but I have thankfully not used it in a while so I wouldn’t know). I cannot explain it except in terms of “it didn’t work”. For a moderately-sized organisation (think hundreds of people), no matter what your search term was, you got hundreds of results, most of them unrelated.
As a consequence, at some point, we ended up with these rules:
The names of modules, programs, services and the like, as used in the internal documentation, could not include their main function in the name, nor the generic name for what they did. So e.g. if we had a load balancer it couldn’t be called Acme Load Balancer or Acme Balancer, as searching for anything that included the terms “load balancer” gave you a few thousand results which ranged from “How to load the office printer paper tray” to the “Balancing personal and work time” training brief.
The authoritative Sharepoint page for that thing ended with a footer that just said “SH-thing-SH” a few dozen times, thus guaranteeing that searching for SH-thing-SH would likely yield that page among the first results (incredibly enough, it did not work all the time).
One of our doodads at $WORK is called “hudsucker”. The one-line repo description: “it is a proxy.” (Yes, the README has a much more useful description. Worth it for the reference.)
The world is boring enough as is. Let’s add more whimsy and cuteness through our service and project names.
I find that I have more time for whimsy when I’m not fielding the umpteenth “what was the purpose of omega star again?” request. I’m not at work for cuteness–I’m there to get paid, support my family, and reduce the annoyance of the lives of my coworkers.
There’s also the unfortunate thing about whimsy: team composition changes over time, and what you find funny today may not be funny later to other folks. Consider the issues you might run into with:
fargo as the name for a service for removing user objects
gestapo for the auditing system
dallas as a name for the onboarding service (since everybody does it)
kali as a name for a resource management and quota enforcement engine
miniluv for your customer service back-office suite
hyrda2 because hydra sucks but version 2 needs to coexist for a while yet with it
Quetzalcoatl after a character from that silly anime Kobayashi’s Dragon Maid (bonus points if you are concerned about second-hand cultural appropriation)
basically any character from Neon Genesis Evangelion
fido (or whatever your dog’s name is) for the fetching service might not be so pleasant after the namesake is sunset from production
2consumers1queue for a data ingest worker pool probably isn’t gonna go over well if anybody on staff has any ranks in knowledge (cursed)
And so on and so forth. I’m put in mind of an old article by Rachel Kroll talking about some logging service or format that was named rather blatantly in reference to either a porno or a sexual act–while this might be a source of chuckles for the team at launch, later hires may object.
As an industry we haven’t gotten over the whimsy of blacklists and whitelists, master and slave, female and male connectors–or hell, even the designation of “user”. If we can’t handle those things, what chance do we think we have with names that seem entertaining in the spur of the moment?
If you still doubt me, consider that AWS seems to engage in both conventions. Which is the easier product to identify, Kinesis or Application Load Balancer? Athena or Secrets Manager? IOT Core or Cognito?
~
I’ll grant that for hobby projects, sure, go nuts. I enjoy thematic character names from anime for my home lab. I used to use names from a particularly violent action movie for cluster nodes.
I’ll also grant that for marketing purposes (at least at a project level) it isn’t bad to have a placeholder name sometimes while things are getting hashed out–though those names often stick around and end up serving as inside baseball for folks to flaunt their tenure.
Lastly, I’ll totally grant that if you by design are trying to exclude people, then by all means really just go hog wild. There are all kinds of delightfully problematic names that function like comic sans to filter folks. Just don’t be surprised if you get called on it.
Lastly, I’ll totally grant that if you by design are trying to exclude people, then by all means really just go hog wild. There are all kinds of delightfully problematic names that function like comic sans to filter folks. Just don’t be surprised if you get called on it.
Meh. The problem with this is that doing gratuitously offensive stuff, like deliberately making your presentations harder to look at, also attracts a bunch of people who think being gratuitously offensive is, like, the coolest thing ever. And when those people find a home in the tech world they soon set about being offensive in the wider community.
Having helped moderate a once fairly significant FOSS thing, I’m pretty convinced that the assholery-positive branding is a bad thing for all of us. It breeds a culture of assholery that we all have to live with no matter where we are.
With all of that said, some cute names don’t concern any sensitive subjects, so I feel like you’re tearing down a straw man, or at least the more strawy half of a composite man. At a previous job we created a service called “counter”, which did have a serious job, but we liked to describe it to management—mostly truthfully—as just being for counting things. You know, like, one apple, two apples… I don’t know if this is funny in anyone’s mind but mine, but the name certainly wasn’t chosen to be a useful description.
Homebrew seem to be using beer brewing names and metaphors throughout. As someone who doesn’t know brewing beer nothing makes sense there. It feels to me like they’re taking a subject I know something about (packaging software) and deliberately make it obscure by renaming everything.
I’m similarly put off Kubernetes. Why invent a whole new vocabulary to name existing concepts? I don’t care enough about Kubernetes to try deciphering their jargon.
If you take an existing domain and change the names of all the things then anyone wanting to participate has to relearn everything you’ve made up (poorly in most cases.)
It makes interacting with you like speaking in a second language you have little command of.
EDIT: Just pause for a second and imagine reading a codebase where classes, functions and variables all have cute names…
I think cutesy naming has its place, but I agree that sub-naming of cutesy things (e.g. cheese shop, wheels, eggs from Python packaging) is bad. Your cutesy name should just be a pun with a more or less deducible relationship to the thing it does (e.g. Celery feeds RabbitMQ). You can have jokes in the documentation, but no joke nomenclature.
TIL! I worked at a company where we used Celery – but with Redis as the backing store – for years and I never made this Celery/RabbitMQ connection before.
I don’t know that I disagree in general, either with you or with friendlysock’s comment. I was responding to a specific thing in it that I found significant. If you want to talk about naming more broadly, know that—at least from my perspective—people don’t all engage with names in the same way, and the purpose of names is situational, learned (think of mathematician vs programmer attitudes to naming variables), and at least in some cases a tradeoff between the interests of the various different people who will be using the name. So I don’t think it’s very useful to have a blanket opinion.
I find that I have more time for whimsy when I’m not fielding the umpteenth “what was the purpose of omega star again?” request. I’m not at work for cuteness–I’m there to get paid, support my family, and reduce the annoyance of the lives of my coworkers.
So much this, and also:
The joke is not going to hold up. It probably wasn’t the funny the first time except to you and maybe one other person, and it’s certainly not going to stand the test of time. I can count on one hand the number of “jokes” in comments and names I’ve come across that have actually made me laugh.
You might think you are adding more “whimsy” into a drab world… in fact, you are probably inducing eye rolls for the decade of programmers who will have to maintain your work.
I’m put in mind of an old article by Rachel Kroll talking about some logging service or format that was named rather blatantly in reference to either a porno or a sexual act–while this might be a source of chuckles for the team at launch, later hires may object.
As an industry we haven’t gotten over the whimsy of blacklists and whitelists, master and slave, female and male connectors–or hell, even the designation of “user”. If we can’t handle those things, what chance do we think we have with names that seem entertaining in the spur of the moment?
Honestly, I think this is very easy to avoid if you have a diverse team and take a minimum amount of care in choosing a name. These examples are valid, but I think they are clearly influenced by the insularity and whiteness of software developers.
I’ve built a series of services over the past few years, and my preference has been animal names.
Coyote is an ACME service
Hedgehog is a routing layer for our Fastly ingress
Mockingbird is an API polling service
Cerberus is an IAM/OAuth/SAML service (I will grant you this one is the least creative)
They were not chosen at random, they were designed to be mnemonic.
While I take your point about AWS, Google does the opposite approach and names everything generically, which makes searching for them a pain in the ass. Also, I think there are distinctly different tradeoffs involved in choosing internal names vs external product names.
I think this is very easy to avoid if you have a diverse team and take a minimum amount of care in choosing a name.
As a practical matter, early-stage startups and small companies do not tend to have diverse teams. Remember, naming is an issue that happens with a team size of 1 and which impacts a team size of…however many future selves or people work on a codebase.
You use Coyote as a harmless example (because ACME like in the coyote and roadrunner cartoons, right?) but similarly banal things pulled from the cartoons like gonzales for a SPDY library in this day and age cannot be guaranteed to be inoffensive. Even if you take care for today’s attitudes there is no guarantee of tomorrow.
On a long enough timeline, anything not strictly descriptive becomes problematic to somebody (and if you don’t like where the industry is heading in that regard, well, that ship has sailed).
As a practical matter, early-stage startups and small companies do not tend to have diverse teams.
The less diverse your team is, the more care you should take.
You use Coyote as a harmless example (because ACME like in the coyote and roadrunner cartoons, right?) but similarly banal things pulled from the cartoons like gonzales for a SPDY library in this day and age cannot be guaranteed to be inoffensive.
I think this only buttresses my point: Gonzalez is clearly a racial/ethnic stereotype. I would never even think of choosing that. This is not rocket science!
On a long enough timeline, anything not strictly descriptive becomes problematic to somebody
Whereas using a purely descriptive name is much more likely to become problematic on a shorter timeline for the reasons stated in the article.
According to Wikipedia, even though Speedy Gonzales is clearly a problematic ethnic stereotype, there has been a thing where the Mexican community has decided they like him, so he’s been uncanceled. Who can predict these things? https://en.wikipedia.org/wiki/Speedy_Gonzales#Concern_about_stereotypes
You use Coyote as a harmless example (because ACME like in the coyote and roadrunner cartoons, right?) but similarly banal things pulled from the cartoons like gonzales for a SPDY library in this day and age cannot be guaranteed to be inoffensive.
Gonzales was once taken off the air out of racial concerns. Hispanic groups campaigned against this decision because Speedy was an a cultural icon and a hero. Eventually he went back on air
Assuming a person or demographics’s view point is it’s own danger. I am not innocent in this regard
I’m well aware of the history there, never fear. That’s why I used him as an example: using that name may annoy well-meaning people, changing that name may annoy somebody with that Hispanic background.
If we’d gone with the boring utilitarian name of spdy-client, instead of being cutesy, we could’ve sidestepped the issue altogether.
Assuming a person or demographics’s view point is it’s own danger.
Sadly, that is not the direction well-meaning people influencing our industry have taken. So, in the meantime, I suggest boring anodyne utilitarian names until the dust settles.
Sadly, that is not the direction well-meaning people influencing our industry have taken. So, in the meantime, I suggest boring anodyne utilitarian names until the dust settles.
That’s a good point
Also sorry for my wording and tone. I’m not happy about how I wrote that
As an industry we haven’t gotten over the whimsy of blacklists and whitelists, master and slave, female and male connectors–or hell, even the designation of “user”.
I’d argue that such metaphors have always been viewed as more on the descriptive side of the spectrum than whimsical or cute. In fact the idea that these terms are descriptive and in some sense “objective” is the most common defense I’ve seen of keeping such terms around, not that people enjoy them. I didn’t have to have anyone explain to me the meaning of master/slave replication when I first heard that term, the meaning is very intuitive. That’s an indictment of our culture and origins, not of metaphor.
My point is not that cute names are always great, or that it’s easy to avoid their pitfalls. It’s not. But I think holding space to be playful with language is often more generative than trying to be dry and descriptive. And it’s when we think we’re at our most objective that our subjectivity can lead us furthest astray.
I think you’re completely missing that every product and open source project that you simply use will have such a name (maybe except OBS), so why is it different for local homegrown stuff?
For the same reason that brand names can be “Amazon” or “Apple” but we don’t start renaming “computers” or “shopping websites” to something else. OSS projects exist in the same space as “brands” – typically a competitive space in which there are multiple competing solutions to the same problem. In that context, differentiating serves a purpose. However, it also has a cost: what your product does needs to be taught and remembered.
It’s possible that at a very large company some of those same forces take effect, but at small and medium companies they don’t. There, following the same principle would be like insisting everyone in the house call the kitchen sink “waterfall”. Why would I do that? “kitchen sink” works perfectly.
So I guess we slightly differ on what cute and descriptive mean. sqlite has sql in it, descriptive, but -lite gives it a double meaning and makes it unique.
logstash_json is a horrible name, imho - because you could theoretically do the same project in many languages, it could be for logstash itself, or some intermediary product. (I don’t remember the specific one in question). Also libpng is very old and the assumption would be “this is the most popular PNG image library, written in C”, maybe because of the (weakly held) naming convention. These days we get many more new projects per year, but in theory a PNG lib in Erlang/Ruby/Brainfuck could also be called libpng, it’s just that the name was taken.
Maybe I am completely wrong here, but I understood the OP’s post more as “don’t use bland descriptive, pidgeonholed names” and you argue more over “don’t do cute names” - so maybe it’s a middle ground.
And yes, I still remember when a coworker wanted to call 2 projects “Red Baby” and “Blue Frog” or something and no one had any clue why, he couldn’t explain it, and we said: Why would one be red and one be blue?
logstash_json has the project slug “Formats logs as JSON, forwards to Logstash via TCP, or to console.”. That’s roughly what I’d expect from the name, something to do with Logstash and something to do with JSON.
libpng is…“libpng is the official PNG reference library.” Sure, a slightly better name would’ve been “png_ref_implementation” or whatever, but again, the name tells me what to expect.
sqlite “implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. “ So, you know, a SQL thingy but not large. Light, if you would. Again, maybe the name could mention the standalone nature, but that’s neither here nor there.
I think that bland, descriptive names are in fact exactly the right answer.
Again, examples from the other side:
nokogiri is a library for Japanese saws…no, wait, it’s for parsing XML and HTML.
Angular is a library for angles…no, wait, it’s an HTML templating and data binding library (among other things).
Beautiful soup is a library about soup…no, wait, another HTML/XML munging library.
Ristretto is a library for short shots of espresso…no, wait, it’s a caching library.
kubernetes is some tool for pilots…wait, no, it’s container orchestration and provisioning.
Prometheus is tool for giving fire to mortals…wait, crap, it’s a time series DB and monitoring setup.
My previous employer had a habit of naming projects after the tech stack they were using. The latest was our Next platform based off of Next.js. They were idiots.
Next is already a bad name for a library, if only because it’s a little too common of a word. I can only imagine how many verbal double takes there were along the lines of “wait, do you mean ‘the next thing’ or ‘the Next thing’?”
I once worked on a project which hit a nice middle ground. Everything got a descriptive name, which was then collapsed into a three letter acronym. So you ended up using the acronyms which picked up a meaning of their own, but they were kind of mnemonic back to the original description if you got stuck.
And it was easier to change the meaning of an acronym as subsystem responsibilities changed.
Can you give some (sanitized/made up, if necessary) examples? I like your description, but I can’t exactly picture how it might work in practice… “Load Balancing Service” -> LBS? Or were your descriptive “input” names less generic than that?
I’m not the person you asked, but in a previous job at an online fashion retailer my team wrote the [Product] “Listing And Details” API, in a service more widely known by its acronym LAD. Later we tacked “Search And” to the front of the service name, and LAD became SALAD. Nobody used the services’ full names. (Other than perhaps when talking to the execs.)
As a veteran of one pile of services named audubon, wilson, servitor, r2d2 and mechanic, and another named view-builder and ledger … I’d rather have the cutesey names. At worst they are just silly. On average creating distinct names is great. Just, please, don’t reuse names that exist outside your ecosystem. I don’t want to have to figure out whether you’re talking about our packer or Hashicorp Packer.
After the number of services hits 20ish, cute names stop being cute, at least for me. The reason is that I can’t immediately recall what each of the names stands for, and making it hard to follow any discussion.
However, there is one benefit of using cute names – if you work in secretive businesses, cute names allow you to discuss the services with colleagues after work, without worrying too much about spilling company secrets. Or at least I’m so told.
One dividing line might be if the names at your company are “pets” or “cattle.” When you have less than a dozen computers/projects, you can give them all cutesy names. When you have more than that, you need descriptive names to keep sane.
I have been in the industry long enough that I agree with both points of view, but for different things. At the end of the day, naming things is hard and you’ll never be 100% happy with any method you pick in the long run. There are always trade-offs, one-offs, and gross hacks. The only reasonable goal is to seek to minimize them.
Giving hosts and devices cute names is perfect for small, self-contained deployments (like my home lab). But they fall down in large heterogeneous environments like a datacenter. The biggest problem I have seen is that a box with a specific role (say, a firewall) might get a cute name like “thor”. Eventually “thor” becomes obsolete and is replaced with a new, more powerful firewall which is named “zeus” but nobody bothers to update any of the docs. A new admin is brought in and a few weeks after they start, zeus stops forwarding packets over a critical weekend and now the poor admin is trying to understand the docs… they talk about thor being the firewall but they have only known zeus… are they both firewalls for different things? Is thor supposed to be online, but isn’t, and that is part of the problem? Only a phone call with someone who has been around longer than the admin could clarify this, but it’s 3 a.m. and the manager is on PTO…
Yes, the problem is ultimately poor documentation and onboarding, but I’ve seen it often enough as a contributing factor to a larger problem that I actively oppose cute names for critical infrastructure if I have any say in it.
On the flip side, I have seen environments that try to package as much metadata as possible into a hostname, which leads you to end up having to log into a host called ‘web9-c23-r1-det.eng.lab.example.com’. Whoops sorry, you accidentally rebooted web9-c22-r1-det.eng.lab.example.com.
My personal opinion is that if once you start encoding more than two pieces of metadata into a hostname, that is the point at which you should just give up, assign the thing a randomly-generated hostname, keep your metadata in some kind of DCIM, and then build your tooling around the DCIM.
My habit is to take the descriptive name, such as directory service, abbreviate heavily (ds), and add some entropy: ds45
It’s easy to type, not too hard to remember, and if the service changes, you can either do a backronym or just don’t bother and consider the name wholly arbitrary.
RFC 1178 [1] echoes the blog post on the ephemerality of responsibilities:
Don’t choose a name after a project unique to that machine.
A manufacturing project had named a machine “shop” since it was going to be used to control a number of
machines on a shop floor. […] It is simply impossible to choose generic names that remain appropriate for very long.
While computers aren’t quite analogous to people, their names are. Nobody expects to learn much about a
person by their name. […] In reality, names are just arbitrary tags.
and has suggestions for choosing arbitrary but memorable names, by using themes:
use colors, such as “red” and “blue”. Personality can be injected by choices such as “aqua” and “crimson”.
Nobody expects to learn much about a person by their name. […] In reality, names are just arbitrary tags.
Filing under “Falsehoods (some) programmers believe about names”
Names have significant meaning at many different levels.
Once upon a time, back in the socialist era of a certain central European country, there was a state company called Správa pošt a telekomunikací – Postal And Telecommunications Administration. Surprisingly, it was responsible for postal services and electronic communications (landlines, airwaves). A single organization was tasked with getting packets of any kind from point A to point B for a whole country, as a service.
Nowadays, one must choose from O₂, T-Mobile, Vodafone, České Radiokomunikace, CETIN, Czech Post, DHL, DPD, GLS, FedEx, Packeta and bazillion other companies on a market with a various regulators for various parts of their offerings.
It might just boil down to whether you build a system or you manage an ecosystem.
If you build a system, you have the freedom to name its parts in a way that clearly conveys their purpose.
If you manage an ecosystem, you need clear labels to assign to various organisms. As the organisms have multiple purposes and constantly evolve, split and merge, you do not have that freedom. Your best bet is to use colorful labels optimized for contrast, so that nobody mistakes one organism for another.
I don’t think that either approach is inherently better than the other. After all, humans are not Borg. But to me, the first approach is designing for clarity at the cost of slower evolution. In retrospect, I tended to create “just another pet service” when I did not have the time or means to coordinate development with my peers. And I have seen others do the same.
It somehow reminds me of the phrase: “I didn’t have time to write a short letter, so I wrote a long one instead.”
Over time cute becomes increasingly annoying and unpleasant. I have to use a piece of software at work which has a joke in an error message. They’ve used the joke in the wrong context so it doesn’t even make sense, but even if it did, what might have been mildly amusing the first time is far beyond unwanted as the months and years pass.
I think it depends on the scope of the project. I worked at a company where everything one team did had a space themed name. I couldn’t remember what was Apollo and what was Moon Rover and what was LEM etc. It would have benefited from descriptive names. But for services that are “pets” then a cutesy name makes sense. As long as you avoid theming.
When I was young qnd new to the industry, “it depends” answers struck me as a cop out—something people said when they were too chicken to either give a decisive answer or come clean and admit ignorance. Now that I’m well into my second decade in the industry, I’ve come to realize that qualifier belongs at the beginning of every claim… although I suppose it depends on the claim.
In this case, “it depends on the scope” jibes with my own experience:
One project I worked on with a descriptive name involved web, firmware, electrical, and mechanical engineers. The scope creep was so bad, it got hard to explain what the features had to do with the name when we took it on the road after nearly two years of hard work. If we had an arbitrary internal name, the inertia behind the marketing name would not have been so difficult to overcome.
I worked for an organization that had developed something of an allergy to the monoliths it had built before. Every new service and component got its own repo and much of our time was spent orchestrating it all. If we hadn’t used descriptive names, I think we would have gone insane.
The most commercially successful software I ever wrote started its life named as an acronym. Said acronym was how it was marketed, too. After a while, we didn’t think too hard about what the acronym stood for. Then one day, the product was rebranded to an English word. My team decided to rename everything in our code and infrastructure to match the new marketing name. I pointed out that much of OS X’s internals bore the acronym “NS” (Next Step) years after Next was acquired and that renaming everything internally to match the new external name was a waste of time, but the argument fell on deaf ears. The rename was highly disruptive and was never fully completed. There are still several instances here and there for which the effort could not, and still now, some five years later, cannot be justified.
Cute names may work well for cloudy SaaS, not COTS applications that will be installed in a customer environment. My preference, either way, is for shorter generic names that are less likely to be off when changes are made. For example, “workerd”, “dbd”, “replicatord”, “dlpd”, and so on.
Descriptive names can form a cohesive vocabulary without an overt top-down plan. Confirming to the scheme that already exists is easy.
Cute names are suitable for marketing, but to make sense as a collection of terms, you need someone to strategically plan those names. Unplanned/grassroots cute names are fine until you have about ten of them. After that, they become hard to learn all at once and it creates insiders and outsiders.
The title is misleading clickbait. This is about long-lived product and service names, not variables and functions, and it’s about unique and memorable names, not “cute”. Sure there’s some overlap, but the main point of the article is that people should be instantly able to understand that you’re talking about an instance, not a concept, and that the instance is long-lived (pet, not cattle).
A title like “Product/service names should be unique and memorable” would’ve worked wonders, but of course is less exciting.
I used cute names to talk about services at my job (well, now previous job) on my blog. I had “Project: Lumbergh” (which is doubly funny, as it is both based on the actual name, and what it does, which is business logic), “Project: Sippy-Cup” (SIP interface to “Project: Lumbergh”), and “Project: Cleese” (it makes sense if you know both the actual project name and Monty Python; all this does is forward data, nothing exciting). The actual names at the company were a mixture of silliness (“Project: Sippy-Cup” had a silly internal name we all used) and functional (SCP, for the “Service Control Point” on the SS7 telephony network).
A lot of the early projects were named after My Little Pony characters. The primary developer at the time was quite the fan.
This only works if you don’t have anybody on your team who will name things in a manner that will eventually anger somebody who wears a tie to work. And that’s not you. There’s always somebody on your team who will do that, and always some suit or blue-hair that will be offended, depending on what kind of bad taste the pun is in.
We had a service responsible for sending push notifications to our ios/android apps that we named Iris after the Greek goddess of the rainbow, the personification of the rainbow and messenger of the gods.
In addition, the cute names should be a single word to avoid having to decide between delimiters which may not consistently work with DNS, AWS resources, database names, etc.
Why not both? You can get away with names being purely cute if you only have a few names to remember, but if you need a spreadsheet to connect cute names to their functionality you’ve gone too far.
Also, coming up with interesting names is a way to improve morale; Not only for the person who is more inclined to write them at 2 AM, but also for the code reviewer who is reading the code over their first cup of coffee.
Yes, yes! Names definitely should be cute! But my favorite type of name is a cute wordplay that hints at the purpose. That brings the best of cute and also a bit of the benefits of descriptiveness.
Many GNU applications have cute names hinting at their purpose: bash, bison, gawk, tar… Also many backronyms are cute and descriptive (if you remember what they stand for): GNU, WINE, LAME…
LAME is an example of the dangers of cutesy naming. GIMP was obviously problematic from the start, so whatever, they chose their conflict, but “lame” has been the target of an anti-ableism campaign for only just the last few years. Whether that campaign is good or bad, there’s no particular reason an MP3 encoded should be wrapped up in the controversy and have to take a side. But back when they chose the name, nobody thought “LAME” was problematic, so they didn’t know they were choosing a side in the culture wars.
Right. I only knew the slang/rap meaning, didn’t even realize there could be issues like that. Am I part of the problem or just a typical second language speaker?
While these things happen, what I like to do is to be descriptive, but broader in first place by giving it a name more akin to the general topic.
While I know the world isn’t perfect and things aren’t always so easy, I’d also argue that maybe either changing the name is the right decision in some situations and creating a new thing rather than bending the old one is a good idea.
There’s another trick you could use. You can use an acronym that might be “cute”, which a reasonable description and should things change the acronym can become its own thing. That seems to have worked for many software projects.
If renaming things is hard it can be a sign of other problems though. In most situations it shouldn’t be that big of a problem and if the reason is external or semi-external it might be worthwhile considering that external dependency.
I vaguely remember a microservice conglomerate at a previous employer, where every service was named after some character from the Marvel universe. I’ll take auth-service any time over Kratos.
Strongly advise anyone thinking of naming some module or feature in their software something incredibly cute to also think about the timebomb you are planting for your bilingual & ESL colleagues.
My team has a very strict “name should be in plain english and descriptive” rule primarily because we have a diverse set of engineers with a varying grasp on English
So true. I like to give them backronyms though, even if it may take a bit of creativity to come up with a sensible word for every letter in PADAWAN for example.
Two other arguments for “cute” names, especially when you’re at a big company with many developers:
Searchability: If your company has hundreds of services, it may be hard to find the docs you want by searching for “load balancer”, but searching for “starfighter” will probably get the results you want.
Overlap and deprecation: Someday you may rewrite your load balancer in Rust! But both the old and new services will likely run in parallel for a while. As you migrate to the new service, it’s probably easier to distinguish “Starfighter” from “BurntMetal”, than “LoadBalancer” from “LoadBalancer2”.
Isn’t a bit of both better? “See Saw” instead of “starfighter”, that way I have a hope in hell of remembering what the service does.
Agree. In a previous job we had a service called “Spiderman” that sent webhooks.
And back in 2005, when we ran stuff on pets rather than cattle, our two firewall machines were called “Asbestos” and “Halon”, which I thought was rather cute and descriptive at the same time.
Ok, that’s a great name! Agree if you can do both that’s even better.
I just know there are people out there reading this and thinking this is some first world problem that is surely not worth misnaming products over, so please allow me to one-up this just to further drive how useful it is and tl;dr how furiously I’m nodding when reading it.
If you’ve ever used Sharepoint, you probably know that its search function was atrocious. (Probably still is, but I have thankfully not used it in a while so I wouldn’t know). I cannot explain it except in terms of “it didn’t work”. For a moderately-sized organisation (think hundreds of people), no matter what your search term was, you got hundreds of results, most of them unrelated.
As a consequence, at some point, we ended up with these rules:
heat_pump_new_customer_landing_page_ai_password_suggester_load_balanceris unlikely to be duplicated and says a bit more to the new guy on the team.One of our doodads at $WORK is called “hudsucker”. The one-line repo description: “it is a proxy.” (Yes, the README has a much more useful description. Worth it for the reference.)
I’m just gonna leave this here: https://youtu.be/y8OnoxKotPQ
You know nothing of my pain… of Galactus’s pain!
Love Galactus.
I consider this my personal manifesto when it comes to naming microservices
Same.
Why is EKS being turned down when Omega isn’t ready?
I have often wondered
I came here to post this video
I as well.
I find that I have more time for whimsy when I’m not fielding the umpteenth “what was the purpose of omega star again?” request. I’m not at work for cuteness–I’m there to get paid, support my family, and reduce the annoyance of the lives of my coworkers.
There’s also the unfortunate thing about whimsy: team composition changes over time, and what you find funny today may not be funny later to other folks. Consider the issues you might run into with:
fargoas the name for a service for removing user objectsgestapofor the auditing systemdallasas a name for the onboarding service (since everybody does it)kalias a name for a resource management and quota enforcement engineminiluvfor your customer service back-office suitehyrda2becausehydrasucks but version 2 needs to coexist for a while yet with itQuetzalcoatlafter a character from that silly anime Kobayashi’s Dragon Maid (bonus points if you are concerned about second-hand cultural appropriation)fido(or whatever your dog’s name is) for the fetching service might not be so pleasant after the namesake is sunset from production2consumers1queuefor a data ingest worker pool probably isn’t gonna go over well if anybody on staff has any ranks inknowledge (cursed)And so on and so forth. I’m put in mind of an old article by Rachel Kroll talking about some logging service or format that was named rather blatantly in reference to either a porno or a sexual act–while this might be a source of chuckles for the team at launch, later hires may object.
As an industry we haven’t gotten over the whimsy of blacklists and whitelists, master and slave, female and male connectors–or hell, even the designation of “user”. If we can’t handle those things, what chance do we think we have with names that seem entertaining in the spur of the moment?
If you still doubt me, consider that AWS seems to engage in both conventions. Which is the easier product to identify, Kinesis or Application Load Balancer? Athena or Secrets Manager? IOT Core or Cognito?
~
I’ll grant that for hobby projects, sure, go nuts. I enjoy thematic character names from anime for my home lab. I used to use names from a particularly violent action movie for cluster nodes.
I’ll also grant that for marketing purposes (at least at a project level) it isn’t bad to have a placeholder name sometimes while things are getting hashed out–though those names often stick around and end up serving as inside baseball for folks to flaunt their tenure.
Lastly, I’ll totally grant that if you by design are trying to exclude people, then by all means really just go hog wild. There are all kinds of delightfully problematic names that function like comic sans to filter folks. Just don’t be surprised if you get called on it.
Meh. The problem with this is that doing gratuitously offensive stuff, like deliberately making your presentations harder to look at, also attracts a bunch of people who think being gratuitously offensive is, like, the coolest thing ever. And when those people find a home in the tech world they soon set about being offensive in the wider community.
Having helped moderate a once fairly significant FOSS thing, I’m pretty convinced that the assholery-positive branding is a bad thing for all of us. It breeds a culture of assholery that we all have to live with no matter where we are.
With all of that said, some cute names don’t concern any sensitive subjects, so I feel like you’re tearing down a straw man, or at least the more strawy half of a composite man. At a previous job we created a service called “counter”, which did have a serious job, but we liked to describe it to management—mostly truthfully—as just being for counting things. You know, like, one apple, two apples… I don’t know if this is funny in anyone’s mind but mine, but the name certainly wasn’t chosen to be a useful description.
It is not only about being offensive.
Homebrew seem to be using beer brewing names and metaphors throughout. As someone who doesn’t know brewing beer nothing makes sense there. It feels to me like they’re taking a subject I know something about (packaging software) and deliberately make it obscure by renaming everything.
I’m similarly put off Kubernetes. Why invent a whole new vocabulary to name existing concepts? I don’t care enough about Kubernetes to try deciphering their jargon.
If you take an existing domain and change the names of all the things then anyone wanting to participate has to relearn everything you’ve made up (poorly in most cases.)
It makes interacting with you like speaking in a second language you have little command of.
EDIT: Just pause for a second and imagine reading a codebase where classes, functions and variables all have cute names…
I think cutesy naming has its place, but I agree that sub-naming of cutesy things (e.g. cheese shop, wheels, eggs from Python packaging) is bad. Your cutesy name should just be a pun with a more or less deducible relationship to the thing it does (e.g. Celery feeds RabbitMQ). You can have jokes in the documentation, but no joke nomenclature.
TIL! I worked at a company where we used Celery – but with Redis as the backing store – for years and I never made this Celery/RabbitMQ connection before.
I don’t know that I disagree in general, either with you or with friendlysock’s comment. I was responding to a specific thing in it that I found significant. If you want to talk about naming more broadly, know that—at least from my perspective—people don’t all engage with names in the same way, and the purpose of names is situational, learned (think of mathematician vs programmer attitudes to naming variables), and at least in some cases a tradeoff between the interests of the various different people who will be using the name. So I don’t think it’s very useful to have a blanket opinion.
Indeed I agree with you. I do seem to have grossly misread your comment and replied to it out of context, my apologies.
Edgelord Simon Peyton Jones
So much this, and also:
The joke is not going to hold up. It probably wasn’t the funny the first time except to you and maybe one other person, and it’s certainly not going to stand the test of time. I can count on one hand the number of “jokes” in comments and names I’ve come across that have actually made me laugh.
You might think you are adding more “whimsy” into a drab world… in fact, you are probably inducing eye rolls for the decade of programmers who will have to maintain your work.
Okay but I’m just going to say that
2consumers1queueis amazing.I am more partial to
1cookie1jarbut that’s also cool.Honestly, I think this is very easy to avoid if you have a diverse team and take a minimum amount of care in choosing a name. These examples are valid, but I think they are clearly influenced by the insularity and whiteness of software developers.
I’ve built a series of services over the past few years, and my preference has been animal names.
They were not chosen at random, they were designed to be mnemonic.
While I take your point about AWS, Google does the opposite approach and names everything generically, which makes searching for them a pain in the ass. Also, I think there are distinctly different tradeoffs involved in choosing internal names vs external product names.
As a practical matter, early-stage startups and small companies do not tend to have diverse teams. Remember, naming is an issue that happens with a team size of 1 and which impacts a team size of…however many future selves or people work on a codebase.
You use
Coyoteas a harmless example (because ACME like in the coyote and roadrunner cartoons, right?) but similarly banal things pulled from the cartoons likegonzalesfor a SPDY library in this day and age cannot be guaranteed to be inoffensive. Even if you take care for today’s attitudes there is no guarantee of tomorrow.On a long enough timeline, anything not strictly descriptive becomes problematic to somebody (and if you don’t like where the industry is heading in that regard, well, that ship has sailed).
The less diverse your team is, the more care you should take.
I think this only buttresses my point: Gonzalez is clearly a racial/ethnic stereotype. I would never even think of choosing that. This is not rocket science!
Whereas using a purely descriptive name is much more likely to become problematic on a shorter timeline for the reasons stated in the article.
According to Wikipedia, even though Speedy Gonzales is clearly a problematic ethnic stereotype, there has been a thing where the Mexican community has decided they like him, so he’s been uncanceled. Who can predict these things? https://en.wikipedia.org/wiki/Speedy_Gonzales#Concern_about_stereotypes
Gonzales was once taken off the air out of racial concerns. Hispanic groups campaigned against this decision because Speedy was an a cultural icon and a hero. Eventually he went back on air
Assuming a person or demographics’s view point is it’s own danger. I am not innocent in this regard
I’m well aware of the history there, never fear. That’s why I used him as an example: using that name may annoy well-meaning people, changing that name may annoy somebody with that Hispanic background.
If we’d gone with the boring utilitarian name of
spdy-client, instead of being cutesy, we could’ve sidestepped the issue altogether.Sadly, that is not the direction well-meaning people influencing our industry have taken. So, in the meantime, I suggest boring anodyne utilitarian names until the dust settles.
Also sorry for my wording and tone. I’m not happy about how I wrote that
I’d argue that such metaphors have always been viewed as more on the descriptive side of the spectrum than whimsical or cute. In fact the idea that these terms are descriptive and in some sense “objective” is the most common defense I’ve seen of keeping such terms around, not that people enjoy them. I didn’t have to have anyone explain to me the meaning of master/slave replication when I first heard that term, the meaning is very intuitive. That’s an indictment of our culture and origins, not of metaphor.
My point is not that cute names are always great, or that it’s easy to avoid their pitfalls. It’s not. But I think holding space to be playful with language is often more generative than trying to be dry and descriptive. And it’s when we think we’re at our most objective that our subjectivity can lead us furthest astray.
I think you’re completely missing that every product and open source project that you simply use will have such a name (maybe except OBS), so why is it different for local homegrown stuff?
For the same reason that brand names can be “Amazon” or “Apple” but we don’t start renaming “computers” or “shopping websites” to something else. OSS projects exist in the same space as “brands” – typically a competitive space in which there are multiple competing solutions to the same problem. In that context, differentiating serves a purpose. However, it also has a cost: what your product does needs to be taught and remembered.
It’s possible that at a very large company some of those same forces take effect, but at small and medium companies they don’t. There, following the same principle would be like insisting everyone in the house call the kitchen sink “waterfall”. Why would I do that? “kitchen sink” works perfectly.
I dunno,
left-padis pretty self-explanatory, as aresqliteandkernel-based virtual machineandlogstash_jsonandopen asset importerandlib_png.There are people using clear, jargon-free naming conventions.
So I guess we slightly differ on what cute and descriptive mean. sqlite has sql in it, descriptive, but -lite gives it a double meaning and makes it unique.
logstash_json is a horrible name, imho - because you could theoretically do the same project in many languages, it could be for logstash itself, or some intermediary product. (I don’t remember the specific one in question). Also libpng is very old and the assumption would be “this is the most popular PNG image library, written in C”, maybe because of the (weakly held) naming convention. These days we get many more new projects per year, but in theory a PNG lib in Erlang/Ruby/Brainfuck could also be called libpng, it’s just that the name was taken.
Maybe I am completely wrong here, but I understood the OP’s post more as “don’t use bland descriptive, pidgeonholed names” and you argue more over “don’t do cute names” - so maybe it’s a middle ground.
And yes, I still remember when a coworker wanted to call 2 projects “Red Baby” and “Blue Frog” or something and no one had any clue why, he couldn’t explain it, and we said: Why would one be red and one be blue?
logstash_jsonhas the project slug “Formats logs as JSON, forwards to Logstash via TCP, or to console.”. That’s roughly what I’d expect from the name, something to do with Logstash and something to do with JSON.libpngis…“libpng is the official PNG reference library.” Sure, a slightly better name would’ve been “png_ref_implementation” or whatever, but again, the name tells me what to expect.sqlite“implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. “ So, you know, a SQL thingy but not large. Light, if you would. Again, maybe the name could mention the standalone nature, but that’s neither here nor there.I think that bland, descriptive names are in fact exactly the right answer.
Again, examples from the other side:
nokogiriis a library for Japanese saws…no, wait, it’s for parsing XML and HTML.Angularis a library for angles…no, wait, it’s an HTML templating and data binding library (among other things).Beautiful soupis a library about soup…no, wait, another HTML/XML munging library.Ristrettois a library for short shots of espresso…no, wait, it’s a caching library.kubernetesis some tool for pilots…wait, no, it’s container orchestration and provisioning.Prometheusis tool for giving fire to mortals…wait, crap, it’s a time series DB and monitoring setup.These names do not enhance understanding.
We still have a service at work that’s named after a billing service we haven’t used since 2018. The readme contains an apology for the name.
My previous employer had a habit of naming projects after the tech stack they were using. The latest was our Next platform based off of Next.js. They were idiots.
Next is already a bad name for a library, if only because it’s a little too common of a word. I can only imagine how many verbal double takes there were along the lines of “wait, do you mean ‘the next thing’ or ‘the Next thing’?”
We also had an internal library called Test User which is an equally terrible name but at least it indicated it’s purpose.
I once worked on a project which hit a nice middle ground. Everything got a descriptive name, which was then collapsed into a three letter acronym. So you ended up using the acronyms which picked up a meaning of their own, but they were kind of mnemonic back to the original description if you got stuck.
And it was easier to change the meaning of an acronym as subsystem responsibilities changed.
Can you give some (sanitized/made up, if necessary) examples? I like your description, but I can’t exactly picture how it might work in practice… “Load Balancing Service” -> LBS? Or were your descriptive “input” names less generic than that?
I’m not the person you asked, but in a previous job at an online fashion retailer my team wrote the [Product] “Listing And Details” API, in a service more widely known by its acronym LAD. Later we tacked “Search And” to the front of the service name, and LAD became SALAD. Nobody used the services’ full names. (Other than perhaps when talking to the execs.)
Pretty much what @stig said in their reply. For example the Haskell Language Server is generally called HLS.
And LBS would be a perfect example too.
Hell, even that might eventually offend someone. Just off the top of my head: KGB, LSD, PMS, NSB might be offensive to certain groups of people.
IMO it’s not wrong to have a cutesy name, as long as you’re not intentionally being perverse or insulting with the name.
As a veteran of one pile of services named
audubon,wilson,servitor,r2d2andmechanic, and another namedview-builderandledger… I’d rather have the cutesey names. At worst they are just silly. On average creating distinct names is great. Just, please, don’t reuse names that exist outside your ecosystem. I don’t want to have to figure out whether you’re talking about ourpackeror Hashicorp Packer.Cute names are a great way to exclude and alienate. It’s additional jargon making outsiders feel unwelcome.
¿Por qué no los dos? The best names are unique and memorable but also have some relation to the functionality.
After the number of services hits 20ish, cute names stop being cute, at least for me. The reason is that I can’t immediately recall what each of the names stands for, and making it hard to follow any discussion.
However, there is one benefit of using cute names – if you work in secretive businesses, cute names allow you to discuss the services with colleagues after work, without worrying too much about spilling company secrets. Or at least I’m so told.
One dividing line might be if the names at your company are “pets” or “cattle.” When you have less than a dozen computers/projects, you can give them all cutesy names. When you have more than that, you need descriptive names to keep sane.
P.S. Any name ending with “d” could be a daemon.
“Did you restart richard?”
I have been in the industry long enough that I agree with both points of view, but for different things. At the end of the day, naming things is hard and you’ll never be 100% happy with any method you pick in the long run. There are always trade-offs, one-offs, and gross hacks. The only reasonable goal is to seek to minimize them.
Giving hosts and devices cute names is perfect for small, self-contained deployments (like my home lab). But they fall down in large heterogeneous environments like a datacenter. The biggest problem I have seen is that a box with a specific role (say, a firewall) might get a cute name like “thor”. Eventually “thor” becomes obsolete and is replaced with a new, more powerful firewall which is named “zeus” but nobody bothers to update any of the docs. A new admin is brought in and a few weeks after they start, zeus stops forwarding packets over a critical weekend and now the poor admin is trying to understand the docs… they talk about thor being the firewall but they have only known zeus… are they both firewalls for different things? Is thor supposed to be online, but isn’t, and that is part of the problem? Only a phone call with someone who has been around longer than the admin could clarify this, but it’s 3 a.m. and the manager is on PTO…
Yes, the problem is ultimately poor documentation and onboarding, but I’ve seen it often enough as a contributing factor to a larger problem that I actively oppose cute names for critical infrastructure if I have any say in it.
On the flip side, I have seen environments that try to package as much metadata as possible into a hostname, which leads you to end up having to log into a host called ‘web9-c23-r1-det.eng.lab.example.com’. Whoops sorry, you accidentally rebooted web9-c22-r1-det.eng.lab.example.com.
My personal opinion is that if once you start encoding more than two pieces of metadata into a hostname, that is the point at which you should just give up, assign the thing a randomly-generated hostname, keep your metadata in some kind of DCIM, and then build your tooling around the DCIM.
My habit is to take the descriptive name, such as directory service, abbreviate heavily (ds), and add some entropy: ds45
It’s easy to type, not too hard to remember, and if the service changes, you can either do a backronym or just don’t bother and consider the name wholly arbitrary.
RFC 1178 [1] echoes the blog post on the ephemerality of responsibilities:
and has suggestions for choosing arbitrary but memorable names, by using themes:
[1] Choosing a name for your computer: https://www.rfc-editor.org/rfc/rfc1178
Names have significant meaning at many different levels.
Once upon a time, back in the socialist era of a certain central European country, there was a state company called Správa pošt a telekomunikací – Postal And Telecommunications Administration. Surprisingly, it was responsible for postal services and electronic communications (landlines, airwaves). A single organization was tasked with getting packets of any kind from point A to point B for a whole country, as a service.
Nowadays, one must choose from O₂, T-Mobile, Vodafone, České Radiokomunikace, CETIN, Czech Post, DHL, DPD, GLS, FedEx, Packeta and bazillion other companies on a market with a various regulators for various parts of their offerings.
It might just boil down to whether you build a system or you manage an ecosystem.
If you build a system, you have the freedom to name its parts in a way that clearly conveys their purpose.
If you manage an ecosystem, you need clear labels to assign to various organisms. As the organisms have multiple purposes and constantly evolve, split and merge, you do not have that freedom. Your best bet is to use colorful labels optimized for contrast, so that nobody mistakes one organism for another.
I don’t think that either approach is inherently better than the other. After all, humans are not Borg. But to me, the first approach is designing for clarity at the cost of slower evolution. In retrospect, I tended to create “just another pet service” when I did not have the time or means to coordinate development with my peers. And I have seen others do the same.
It somehow reminds me of the phrase: “I didn’t have time to write a short letter, so I wrote a long one instead.”
Over time cute becomes increasingly annoying and unpleasant. I have to use a piece of software at work which has a joke in an error message. They’ve used the joke in the wrong context so it doesn’t even make sense, but even if it did, what might have been mildly amusing the first time is far beyond unwanted as the months and years pass.
Sounds like PHP’s infamous Hebrew parse error message.
I think it depends on the scope of the project. I worked at a company where everything one team did had a space themed name. I couldn’t remember what was Apollo and what was Moon Rover and what was LEM etc. It would have benefited from descriptive names. But for services that are “pets” then a cutesy name makes sense. As long as you avoid theming.
When I was young qnd new to the industry, “it depends” answers struck me as a cop out—something people said when they were too chicken to either give a decisive answer or come clean and admit ignorance. Now that I’m well into my second decade in the industry, I’ve come to realize that qualifier belongs at the beginning of every claim… although I suppose it depends on the claim.
In this case, “it depends on the scope” jibes with my own experience:
Cute names may work well for cloudy SaaS, not COTS applications that will be installed in a customer environment. My preference, either way, is for shorter generic names that are less likely to be off when changes are made. For example, “workerd”, “dbd”, “replicatord”, “dlpd”, and so on.
The Windows print server at my university was called
beelzebub. Get you a name that’s cute and descriptive!Descriptive names can form a cohesive vocabulary without an overt top-down plan. Confirming to the scheme that already exists is easy.
Cute names are suitable for marketing, but to make sense as a collection of terms, you need someone to strategically plan those names. Unplanned/grassroots cute names are fine until you have about ten of them. After that, they become hard to learn all at once and it creates insiders and outsiders.
s/confirming/conforming
The title is misleading clickbait. This is about long-lived product and service names, not variables and functions, and it’s about unique and memorable names, not “cute”. Sure there’s some overlap, but the main point of the article is that people should be instantly able to understand that you’re talking about an instance, not a concept, and that the instance is long-lived (pet, not cattle).
A title like “Product/service names should be unique and memorable” would’ve worked wonders, but of course is less exciting.
I used cute names to talk about services at my job (well, now previous job) on my blog. I had “Project: Lumbergh” (which is doubly funny, as it is both based on the actual name, and what it does, which is business logic), “Project: Sippy-Cup” (SIP interface to “Project: Lumbergh”), and “Project: Cleese” (it makes sense if you know both the actual project name and Monty Python; all this does is forward data, nothing exciting). The actual names at the company were a mixture of silliness (“Project: Sippy-Cup” had a silly internal name we all used) and functional (SCP, for the “Service Control Point” on the SS7 telephony network).
A lot of the early projects were named after My Little Pony characters. The primary developer at the time was quite the fan.
This only works if you don’t have anybody on your team who will name things in a manner that will eventually anger somebody who wears a tie to work. And that’s not you. There’s always somebody on your team who will do that, and always some suit or blue-hair that will be offended, depending on what kind of bad taste the pun is in.
We had a service responsible for sending push notifications to our ios/android apps that we named Iris after the Greek goddess of the rainbow, the personification of the rainbow and messenger of the gods.
In addition, the cute names should be a single word to avoid having to decide between delimiters which may not consistently work with DNS, AWS resources, database names, etc.
Why not both? You can get away with names being purely cute if you only have a few names to remember, but if you need a spreadsheet to connect cute names to their functionality you’ve gone too far.
Also, coming up with interesting names is a way to improve morale; Not only for the person who is more inclined to write them at 2 AM, but also for the code reviewer who is reading the code over their first cup of coffee.
Yes, yes! Names definitely should be cute! But my favorite type of name is a cute wordplay that hints at the purpose. That brings the best of cute and also a bit of the benefits of descriptiveness.
Many GNU applications have cute names hinting at their purpose: bash, bison, gawk, tar… Also many backronyms are cute and descriptive (if you remember what they stand for): GNU, WINE, LAME…
LAME is an example of the dangers of cutesy naming. GIMP was obviously problematic from the start, so whatever, they chose their conflict, but “lame” has been the target of an anti-ableism campaign for only just the last few years. Whether that campaign is good or bad, there’s no particular reason an MP3 encoded should be wrapped up in the controversy and have to take a side. But back when they chose the name, nobody thought “LAME” was problematic, so they didn’t know they were choosing a side in the culture wars.
Right. I only knew the slang/rap meaning, didn’t even realize there could be issues like that. Am I part of the problem or just a typical second language speaker?
Is the only safe approach to avoid all wordplay?
While these things happen, what I like to do is to be descriptive, but broader in first place by giving it a name more akin to the general topic.
While I know the world isn’t perfect and things aren’t always so easy, I’d also argue that maybe either changing the name is the right decision in some situations and creating a new thing rather than bending the old one is a good idea.
There’s another trick you could use. You can use an acronym that might be “cute”, which a reasonable description and should things change the acronym can become its own thing. That seems to have worked for many software projects.
If renaming things is hard it can be a sign of other problems though. In most situations it shouldn’t be that big of a problem and if the reason is external or semi-external it might be worthwhile considering that external dependency.
I vaguely remember a microservice conglomerate at a previous employer, where every service was named after some character from the Marvel universe. I’ll take auth-service any time over Kratos.
[Comment removed by author]
Strongly advise anyone thinking of naming some module or feature in their software something incredibly cute to also think about the timebomb you are planting for your bilingual & ESL colleagues.
My team has a very strict “name should be in plain english and descriptive” rule primarily because we have a diverse set of engineers with a varying grasp on English
So true. I like to give them backronyms though, even if it may take a bit of creativity to come up with a sensible word for every letter in PADAWAN for example.