I was on a team that used cute names. It was fun during the development cycle, but super annoying when you're dealing with an outage. Not only did we constantly get misassigned tickets, but it can be difficult in that moment to remember if you're supposed to engage the Dynamic Pterodactyls or the Hopping Hippos.
I've liked "cute" names that are related to their original responsibility in some way. E.g. we had a messaging service called "McFeely" after Mr. McFeely's Speedy Delivery Service from Mr. Roger's Neighborhood.
When someone gets onboarded, they'll encounter these names and will have to ask. It's a short anecdote, and it sticks. I'm personally a fan of these, as long as the stretch isn't too far. Themes around names can be nice, too. (As with the above, Mr. Roger's Neighborhood.)
> Internet socialists / communists / transhumanists seem to infuse their content with a “chibi” vibe, filled with cuteness and hearts. Disagree with them politically, though, and watch out. The sunshine and roses suddenly become bloody slavering fangs.
Probably because it appears they are fishing for a political fight, and they are referencing their own vaguely related post from four days ago as if someone else wrote it ten years ago.
Right? Also, where are the "bloody slavering fangs"? It's just a blog post about whimsical naming. Some people will agree, some will disagree. Hardly a touchstone of "internet communists" or "transhumanists". And a bizarre perspective, considering who is behind recent events in the USA and Brazil.
The comment did not address any points in the article. It only mentions their view that a certain group uses this type of name. That's the "vague" part.
The saddest thing about our modern times is seeing how rejecting the status quo has been incorporated into politics. Once upon a time, one would reject politics and factionalism together with the cutesy corporate agenda you're ranting against.
Now you get politicised posers like you blaming everything on "Internet socialists" and "communists".
Party politics is not punk. Stop pretending it is.
I've found this practice very useful when naming servers, which is an idea I picked up from the Debian project's infrastructure. A physical machine will have a cute hostname, and then the actual service it provides is a CNAME (DNS alias) to it.
That way, the physical identity remains steady, but the responsibilities (CNAME) can move around (usually because of upgrade)
I think it's excused if machine fulfills more than one function at once or needs some distinctor among many that fulfil similar function.
If it is a LDAP server in DC1 it should just be "dc1-ldap" or "dc-ldap1" if you have few in redundancy (with actual service being either under "ldap" or "dc-ldap").
But if it is a kitchen sink server running a bunch of services, eh, mjollnir will do, and if you do "ssh ldap" you will ssh to server that hosts LDAP service, regardless of what cute name it will have
What? You don't want to sift through hundreds of pokemon and anime characters names totally unrelated to the variables and functions of the API you need to use for your job? I'll just write "not a team player" in your annual review.
It's like trying to learn frontend dev tools all over again. Too much gulping and grunting yarn for my tastes. I hear somehow bunnies are involved as well these days?
Cute names are fun when for a few special things here and there.
Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize just to navigate through the basics of trying to get your job done.
New hires suffer the most. It’s an extra layer of company-specific jargon that you have to learn to even begin to understand what your peers are talking about.
Yeah but surely there is a directory somewhere that explains this?
I mean - the problem is not the number of names but the number of services. A new hire still isn't going to be able to work out what a service does just based on the name, regardless of how whimsical or apt it is.
"policy-engine" might seem to be a good name for a service, but it's only one level below "kevin" in terms of opaqueness, especially when there are probably several policy related services.
>Yeah but surely there is a directory somewhere that explains this?
No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.
But that's my point. You start writing a new policy engine, and you think the name is obviously descriptive. But in 12 months time, it's not so obvious any more, and also you probably have 3 different policy engines for different use cases.
At least until it also starts converting gifs to webm, and soon other formats like mp4, and since it's being used for video it needs subtitle support in various languages.
Directories somewhere that pedagoically explain all the codenames, nah that doesn't necessarily exist in the company until it grows larger. It might just be a quagmire for new hires in a growing company.
One of the cute names horrowshow for me is Chef. Everything is based on some supposedly cooking analogue that just does not fit with (at least my) mental model of IaC.
This is because cook books while useful, aren’t entertaining stories.
Now if they named it after a good character from a story everyone knows, say the hunter from the big bad wolf, and it’s purpose was to chop up evil wolves taking advantage of grandmas and little girls with baked goods, then everyone knows that character, and as long as the purpose of the service is to defeat impostors trying to do harm then it is fitting.
And if the junior doesn’t know the story of little red riding hood, well then it is your lucky day and you are one of the 1 in 10000 who gets to tell them the story.
And when the other person in the conversation looks perplexed or lost, just repeat it again, slowly, and add emotion to some of the syllables. They'll get it eventually.
Absolutely this! In case anyone isn't aware of the insane thematic naming in Chef:
Chef = a configuration management tool
Recipe = an individual Ruby script that makes sure something is installed and configured correctly (e.g. a mysql recipe)
Cookbook = a bundle of recipe(s) and basic metadata (what do these recipes do, who wrote them, etc.)
Supermarket = a community site with common cookbooks, what others would call a "hub", "central repository", "marketplace" or "store"
knife = a command line tool for managing your chef installation
Test Kitchen = a test suite runner
Cookstyle = a code linter
However, now that Chef has gone full Enterprise (never go full Enterprise), the names are now all enterprisey-sounding: everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword you don't", harnesses the CxO's FOMO. Chef Habitat = write declarative rules for applying cookbooks to machines. Chef InSpec = auditing/compliance. Chef Workstation = what you would have normally installed anyway, the development kit and runtime tools, but now it's EnTeRpRiSe, ...
Puppet went full enterprise too and now there's a dizzying amount of "products" catering to your needs.
It's written on the wall for Ansible, Red Hat/IBM is busy churning out the product space already.
It's weird that there's so much money in enterprise IT. If anything, they should know the value of standards and reference implementations.
Almost 25 years ago, SSH went full enterprise and promptly died. Somehow the need for a simple remote shell protocol didn't, though, and now OpenSSH is instead perhaps the most valuable tool we have.
I had no idea there was ever a company called SSH but apparently they still exist . Seems they were way ahead of the curve on what became known as "open core"
I worked at a place where people would write their own wrappers for Chef things, name them, and then refer to them by that name. "Dave, nobody has any idea what 'spork' is."
I say, go for both. Go all Boaty McBoatface on that thing. Boaty McBoatface is silly, but it is unarguably a memorable name for a boat.
There are other, less silly, but equally memorable (and maybe even cute) descriptives out there.
On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.
is it ever a problem in software engineering, that you can't remember what that component's name is?
I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, their lib would not even come up.
Question wasn't if people forget names in software, it's whether forgetting names is a problem. Like I forget names of things in the codebase MULTIPLE times per day, but I don't, and am not aware of anyone naming variables, functions etc in order for them to be memorable (as opposed to descriptive). I neither need nor want to memorize those names, I have other things more interesting to fill up my memory with.
> I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name
This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.
What I agree with is that it is not strictly necessary, but that is a label that you can stick on a lot of things. Things that make our lives easier. Memorability of names is not a necessity in software engineering, just as is descriptiveness, but it certainly does not hurt.
I have the opposite problem as a recent new hire: when "cute" project names show up in a conversation, it signals something company-specific I need to learn about. When descriptive project names are used (especially if the projects are using really generic one or two word names like "routing-service"), it is harder to realize that people are talking about an implementation of a concept rather than a well-known concept.
This is basically by fast the best argument to use cute names over some main components, and by "main" I mean when there are few of them, less than a dozen or so.
An old name made of well-known technical words can easily suggest a level of complexity much smaller than what it has evolved into and therefore developers -specially new devs- should look it up instead of assuming what it does based on potentially misleading namings.
What's not to understand about the account-provider-router-service? It's key to the business-data-sync service. We're working on a new account-provider-aggregator to replace it though.
I tend to jump to the opposite conclusion. If a name is cute I assume it’s something open source, named for marketing or SEO. If a name is descriptive I assume it’s probably internal.
Even HN frontpage sometimes be "How I use Kawai Wasabi on Yakotori under Sashimi" and there'd be 100 comments, all of them serious. Makes one feel excluded.
Why would anyone still build it manually? Tokidoki automates all of that, and all you have to do configure your .toki bundles after you've installed the right SpaghettiWare layer for your architecture and connect it with either Tutti or Frutti. Easy peasy lemon squeezy! Oh that reminds me you do need Squeezy running in the background.
Uh ? Aren't your .toki bundles autogenerated from picks in the CherryOrchard directory ? Don't touch them - let the NoodleBlossom pipeline trellis abstract that for you !
Oh goodness, well I was just on a two week vacation and it looks like NoodleBlossom was created last week, I feel like some kind of cave person over here! Trellis pipelines are slick!
Tech naming has become a pet peeve of mine. Too many common nouns are being used.
Something like coffeescript is at least distinct but then you get a hundred things that will be called something like apple juice, based on some in-joke connected to a stack that will be called orchard.
And at a conference, you'll have two animated people arguing over the use of...well...I didn't quite get it, it was loud, but it was the solution to all things and I'll never find out what it was, because what I _thought_ I heard was Spogdog, but Google's got NOTHING.
The whole Cloud Native Landscape is full of BS like this: Kong, Skipper, Harbor, Calico, Helm, Linkerd, Flannel, you add the next 50 or so project that I forgotten. It makes the entire thing really complex to navigate, and impossible to talk to others about, because they may have plugged in some network you don't know, but you don't know that it's a network, because the name provides zero clues. Or there might be clues, if English is your native language, otherwise too bad.
It's this needless layer of jargon that doesn't help with the understand of the solution.
Sure, if there's a reasonable chance that your project becomes absolutely massive, then a unique name is a great idea. For internal project, don't be cute, just call the thing by its function. Your warehouse management system should just be "the WMS", not FluffoTron. Should it happen to take on new functionality, then either split that out in a separate project, or just rename the whole thing.
I'm not a huge fan of cutesey names but a lot of those names are variations on or homages to Kubernetes (Greek for "Helmsman"): e.g Skipper, Harbor, and Helm from your list.
The problem with linkerd is that we already use the word "linker" and have an established nomenclature for adding a "d" to indicate a daemon. While linkerd might be a daemon, it's not a linker daemon.
Also becomes awkward and distracting having to explain to other peoples’ lawyers (or government officials!) what those cute names represent when things go wrong.
You can have the worst of both worlds. I've worked at three(!) seperate companies which have had projects called 'Hydra' (and the number of people who were ignorant of what the Hydra was, and why it might not have been a great name for a software project never ceased to amaze me.)
I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and generic and not terribly uncommon end up being the worst.
I worked at a startup with a bird theme for a bit under 4 years. There were three separate things named Nightingale in that time. By the time I left, it was kind of a joke to suggest that as the name for random things.
Mozilla was named because the browser was going to be a "Mosaic killer". They made a bug tracker which they named bugzilla. Atlassian made their own bug tracker called Jira, in reference to the japanese transliteration for godzilla, "gojira", which is similar to bugzilla.
This would actually make the situation in TFA worse. The new hires would assume that foober foos when actually it's being used to bar. Either way there's a need to memorise - without cute names you gain the additional problem of close but dangerously wrong assumptions.
Reading documentation is not a bad expectation of a developer.
> Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize
Now imagine trying to navigate hundreds of things that are descriptively named wrong. The argument isn't between (A) cutesy names, and (B) accurate descriptive names. B is obviously better. But that's a fantasy world that doesn't exist. The argument is between A and (C) descriptive names that rot over time (quickly or slowly), which is actual reality.
No, the alternative is having 100s of things that are basically right, with a few that are misleading. I'll take that any day over all cute names, because I only have to remember the exceptions. Not theoretical, I've been in that situation. Also, purpose drift is technical debt. Using meaningless names is just a way of hiding that debt. A service that doesn't match it's name has evolved into a bad place and needs to be refactored. You want to be able to see that.
This is the sort of nonsense argument people use to justify not writing comments. "But the comment might get outdated!!"
Yes it might. But it probably won't, or it will be obviously outdated, or outdated in trivial ways or you can use Git blame to check how the code was when it was written. All of which is better than no comments 99% of the time.
The number of times I've read a comment and eventually thought "oh damn that was misleading, I wish that comment wasn't there" is like... 10 in my whole life.
The number of times I've thought "why does the foo-service also do bar? I wish they'd named it completely randomly instead" is precisely zero.
> New hires suffer the most. It’s an extra layer of company-specific jargon that you have to learn to even begin to understand what your peers are talking about.
I wonder if that's the point, and why certain people use weird names for things. They're senior engineers, they get a nice salary, it's rational (albeit not in the interest of their employer) to prevent their job getting taken over by a junior developer. So they have to set up roadblocks, moats, barriers to entry etc., and weird service names are one such barrier.
In general team members are going to look after their own interests (e.g. set up roadblocks), but if this sort of stuff goes on it shows bad engineering leadership within the company, as it's the leadership's responsibility to stamp down on this sort of behaviour.
At my last job, I kept a list in my notes of about 20 service names with explanations of what they did because they all had cutesy names that gave no indication of their purpose and I could never remember which one was which.
Descriptive name guards from feature creeping because every one understands the scope of service. If it is always tempting to add new features to the existing services, creation of new services should be done to be easier.
Right, the article itself actually uses this as a compelling reason for cute names. If I release "X service", then it inevitably becomes "X and Y service" and the old name is now misleading.
Yeah this seems like a terrible argument. Here is what onboarding looks like, if we all followed this:
“Okay so, the part of the app you’re working on is weeble-wobble which handles transactions. Weeble-wobble interfaces with poopy-leg to create financial reports, and with screaming-kidney to do fraud analysis.”
Maybe this is fine for devops? I mean, if pets, not cattle is the regime within the org
Star trek has many names too. It's just that they get more and more obscure.
Which is fine if it's just you. But if it's a company and you hire someone who doesn't rewatch TNG every weekend, then it doesn't help that you know the daud's wife's name.
And that would hurt the business.
I'm sure every character in the star wars cantina has a name. That's not the point.
> I don't want to be the one to advocate for delaying features so we can rename broadcast-service to broadcast-and-new-responsibility-service. That's going to be an unpleasant conversation with your product manager, for good reason: Because this never should have happened, and it's a waste of time to change the name.
Sounds like there's a workflow problem around renaming services?
It's funny that the author brings up the point about names being for identity rather than responsibility. Historically, names have often signified both. Ask anyone called Smith or Cook or Archer.
Nice theory. In practice all this does is make it harder to onboard new people. Quick test: It's your 2nd week on the job. Some core system just went down, and you've been assigned to figure out what service is causing the trouble. What makes for easier, more transparent reading of error logs, the name "ServiceRouter", or the name "Trainstation"? It's not just a matter of the name being perfectly descriptive for any and all responsibilities, in zero-context situations it can be good just to give a hint that yes, this is a service, and yes, it at one point handled routing, so it seems like an okay place to start. The more obscure the name, the longer I spend reading about some obscure same-named repository and wondering how it's related to the issue at hand.
That said, I think a certain degree of whimsy is definitely acceptable (necessary?) in the workplace and should be encouraged. I can support silly names for the sake of having fun. But maybe if it's something important, foundational, try to remember it may not be as fun for someone 5 years down the line at 2AM.
Who would assign a core system failure resolution task to a newbie who's been there two weeks?
Also, per the article, the problem is that "ServiceRouter" maybe isn't as obvious as you might think. The actual HTTP routing might be done by "HttpPathInspector". "ServiceRouter" is actually a non-core message router for analytics.
I've been in situation where "ServiceRouter" was also doing feature flagging so when debugging 5-year old impossible to solve issue no one looked at it (because, well, it was ServiceRouter not ServiceRouterAndFeatureFlaggerAppendage, in spirit of the article) - YMMV.
Another fun story I recall happened when server technician had to replace faulty HDD in RAID array. We ensured that the serial numbers were correct in correspondence yet still technician replaced the wrong one. When we complained we got into funny argument that we should use color code to designate HDD. Serial numbers are hard to pass and easy to confuse (especially since they were next to each other). But color coding wasn't provided to us, customers - we couldn't use it even if we wanted to.
Naming is hard but descriptive name doesn't guarantee correctness or helpfulness just as non-descriptive wont ease understanding or improve communication without proper directory or conceptual mapping. Does DatabaseServer-EU-259-aed6f give more information than "dumpstation" in scenario where it relates to single server wordpress blog.
In the end it's still about difficulty of naming, middle ground and consistence. Ubuntu for years used letter coding with animals and it worked. MacOS uses naming scheme for releases even though iOS and iPadOS are numbered only. Some people would be confused that Windows 95 is after Windows 3.11 and before Windows 10 and Windows 11. Not sure if Docker still use cutesy auto generated names for containers but it was fun to use.
They’re both right, of course — the author and his colleague — and this blog post makes an excellent point as to why.
I will switch from descriptive to cute once I’ve reached a certain level of abstraction. That level can best be defined as the level where I will need to start advocating for the idea with other engineers.
A new ssh wrapper for automating access to the manufacturing robots? example.factory.sshtool
A log file parser for extracting text-only errors across multiple robot.log lines into structured error objects? example.factory.logs
A quarter-long project to build a new abstraction over all our thirteen different categories of manufacturing robot we have deployed on site that replaces a bunch of shell scripts written by the former CTO, and then actually replace all those shell scripts with the new thing, with tests? example.factory.duckling
I’d promote it as being named after how ducks imprint on their mother and follow her lead. Kind of a nod to the robots, but also to the former CTO. Cute names can feel a little saccharine but it really helps build advocacy obviously — it’s ultimately a branding / marketing exercise.
If you do that day-in day-out at the level of the ssh tool or the log parser — projects that should ideally have a low level of controversy compared to the shell script rewrite — then people are going to get annoyed with you.
While scope expansion is a potential issue, a service by its nature should not inherit scope outside of its core responsibility. If it does (an auth service with some type of user information is clearly taking on more scope than it should), a practical name will reveal that right away.
The issues with practical names mentioned in this article are pretty small when compared to the very real issue of understanding cute-named services. If AuthService goes down, I know what that means. If Balthasar goes down, I now have to understand what that is, look up documentation, find the right team, etc.
Baby, meet bathwater. "Names are hard to change" is supposedly the reason to give things meaningless random names. Great, now you get the worst of both worlds, the meaningless name is now synonymous with a purpose (the very thing you tried to avoid, well, tough luck, that's not how human psychology works!) AND newcomers to the company/org will have zero idea what "galactus" and "goatpen" are or what they do.
Interesting, cute even. But I will stick with boring law firm names.
Firstly when I was a so-called manager cute project names were a nightmare - who could remember what "project mayhem" was - lift and shift half the the data centre or was it refactoring the stupid accounts hack. Project refactor-accounts-monthly-charge is something at exec level everyone can remember. It's fine for project-negotiate-possible-sale-of-dutch-office to be called project mayhem, because powerpoints get acciendetaly shared, emails get read, but there aren't many of those.
Secondly Sam used to be called Sam Smith because he was the smith. If he becomes used for something else people will create a directory (in their heads or in reality). And that's the key here.
I still lament the time when a former team had to rename a service referencing a noble sea creature to its perfunctory backend purpose, and our corresponding service with a rhyming name referencing hair loss had to be renamed to reflect its unambitious web target.
The mistake the author is making is that indeed his friend Sam will still be Sam (even if he changes jobs) but he is a human that exists regardless of his function. Variable names’ on the other hand only exist to serve a function, when the function is gone the names that refer to it should be gone too. If you have a ml-worker node and you no longer need an ml worker, you refactor the code to remove those. It’s much easier to remove than to rename, and consistent mild refactoring ( or code massage if you will) means you’re more likely to remember what lurks in the dark corners of your code base.
Cute names are human readable. Descriptive names are hard to search for and hard to say. They are often overloaded. Best are cute but descriptive acronyms. Your brain remembers cute more, so optimize for your brain.
497 comments
[ 3.2 ms ] story [ 390 ms ] threadWhen someone gets onboarded, they'll encounter these names and will have to ask. It's a short anecdote, and it sticks. I'm personally a fan of these, as long as the stretch isn't too far. Themes around names can be nice, too. (As with the above, Mr. Roger's Neighborhood.)
https://news.ycombinator.com/item?id=34271510
> Internet socialists / communists / transhumanists seem to infuse their content with a “chibi” vibe, filled with cuteness and hearts. Disagree with them politically, though, and watch out. The sunshine and roses suddenly become bloody slavering fangs.
Kinda proves your point.
Now you get politicised posers like you blaming everything on "Internet socialists" and "communists".
Party politics is not punk. Stop pretending it is.
That way, the physical identity remains steady, but the responsibilities (CNAME) can move around (usually because of upgrade)
If it is a LDAP server in DC1 it should just be "dc1-ldap" or "dc-ldap1" if you have few in redundancy (with actual service being either under "ldap" or "dc-ldap").
But if it is a kitchen sink server running a bunch of services, eh, mjollnir will do, and if you do "ssh ldap" you will ssh to server that hosts LDAP service, regardless of what cute name it will have
honk, zonk, honker, dunk, xonk... the list goes on. This is supposed to be ActivityPub server.
Fun. Not.
I thought you were kidding, but you're not. Sad.
At work we tend to create backronyms for/from the cute names which is our way of having our cake and eating it too.
[0] https://youtube.com/watch?v=y8OnoxKotPQ&si=EnSIkaIECMiOmarE
Cute names are a nightmare when a company has accumulated hundreds of quirkily named things that you have to memorize just to navigate through the basics of trying to get your job done.
New hires suffer the most. It’s an extra layer of company-specific jargon that you have to learn to even begin to understand what your peers are talking about.
I mean - the problem is not the number of names but the number of services. A new hire still isn't going to be able to work out what a service does just based on the name, regardless of how whimsical or apt it is.
"policy-engine" might seem to be a good name for a service, but it's only one level below "kevin" in terms of opaqueness, especially when there are probably several policy related services.
No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.
Nevertheless, the same phenomenon that leads to multiple directories will also mean that supposedly "descriptive" names, will not be.
So I think policy-engine might have seemed descriptive but it just wasn't whereas image-optimization-engine was descriptive.
Very few times somebody starts something like this. And yes, they do have cute names, because they don't have any short identification.
It can point "policy-engine" to which host runs it. Or, even better, make it resolve the IP address directly!
And if the junior doesn’t know the story of little red riding hood, well then it is your lucky day and you are one of the 1 in 10000 who gets to tell them the story.
Then when things go off the rails, I can say 'Shaka, when the walls fell'
Darmok and Jalad at Tanagra.
Chef = a configuration management tool
Recipe = an individual Ruby script that makes sure something is installed and configured correctly (e.g. a mysql recipe)
Cookbook = a bundle of recipe(s) and basic metadata (what do these recipes do, who wrote them, etc.)
Supermarket = a community site with common cookbooks, what others would call a "hub", "central repository", "marketplace" or "store"
knife = a command line tool for managing your chef installation
Test Kitchen = a test suite runner
Cookstyle = a code linter
However, now that Chef has gone full Enterprise (never go full Enterprise), the names are now all enterprisey-sounding: everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword you don't", harnesses the CxO's FOMO. Chef Habitat = write declarative rules for applying cookbooks to machines. Chef InSpec = auditing/compliance. Chef Workstation = what you would have normally installed anyway, the development kit and runtime tools, but now it's EnTeRpRiSe, ...
It's written on the wall for Ansible, Red Hat/IBM is busy churning out the product space already.
It's weird that there's so much money in enterprise IT. If anything, they should know the value of standards and reference implementations.
Almost 25 years ago, SSH went full enterprise and promptly died. Somehow the need for a simple remote shell protocol didn't, though, and now OpenSSH is instead perhaps the most valuable tool we have.
There are other, less silly, but equally memorable (and maybe even cute) descriptives out there.
On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.
is it ever a problem in software engineering, that you can't remember what that component's name is?
I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, their lib would not even come up.
Yes. When the names are descriptive or bland, it's almost impossible to remember what it is.
This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.
What I agree with is that it is not strictly necessary, but that is a label that you can stick on a lot of things. Things that make our lives easier. Memorability of names is not a necessity in software engineering, just as is descriptiveness, but it certainly does not hurt.
An old name made of well-known technical words can easily suggest a level of complexity much smaller than what it has evolved into and therefore developers -specially new devs- should look it up instead of assuming what it does based on potentially misleading namings.
This is how it ends up sounding like.
"video-encoder is not working"
"oh, you mean ffmpeg"
"no, our microservice is called video encoder"
Also they are not neccesarily one or the other, you can name something that hints at its function but it is not straight dictionary description of it.
using cute names shouldn't be an alternative to learning to name things properly
When using Yakotori you should use Tare instead.
Something like coffeescript is at least distinct but then you get a hundred things that will be called something like apple juice, based on some in-joke connected to a stack that will be called orchard.
And at a conference, you'll have two animated people arguing over the use of...well...I didn't quite get it, it was loud, but it was the solution to all things and I'll never find out what it was, because what I _thought_ I heard was Spogdog, but Google's got NOTHING.
(If only I knew it was SpŌgDog)
It's this needless layer of jargon that doesn't help with the understand of the solution.
Sure, if there's a reasonable chance that your project becomes absolutely massive, then a unique name is a great idea. For internal project, don't be cute, just call the thing by its function. Your warehouse management system should just be "the WMS", not FluffoTron. Should it happen to take on new functionality, then either split that out in a separate project, or just rename the whole thing.
That said, I have to object to including linkerd. It links services together, and it's a daemon. Can't get much clearer than that.
I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and generic and not terribly uncommon end up being the worst.
(I have a soft spot for clever names, my favorite is still Leiningen the clojure build system: https://en.wikipedia.org/wiki/Leiningen_Versus_the_Ants)
I managed to avoid creating any new tools or services with bird names during my time there, though it was tempting to do so.
Reading documentation is not a bad expectation of a developer.
Now imagine trying to navigate hundreds of things that are descriptively named wrong. The argument isn't between (A) cutesy names, and (B) accurate descriptive names. B is obviously better. But that's a fantasy world that doesn't exist. The argument is between A and (C) descriptive names that rot over time (quickly or slowly), which is actual reality.
Yes it might. But it probably won't, or it will be obviously outdated, or outdated in trivial ways or you can use Git blame to check how the code was when it was written. All of which is better than no comments 99% of the time.
The number of times I've read a comment and eventually thought "oh damn that was misleading, I wish that comment wasn't there" is like... 10 in my whole life.
The number of times I've thought "why does the foo-service also do bar? I wish they'd named it completely randomly instead" is precisely zero.
I wonder if that's the point, and why certain people use weird names for things. They're senior engineers, they get a nice salary, it's rational (albeit not in the interest of their employer) to prevent their job getting taken over by a junior developer. So they have to set up roadblocks, moats, barriers to entry etc., and weird service names are one such barrier.
In general team members are going to look after their own interests (e.g. set up roadblocks), but if this sort of stuff goes on it shows bad engineering leadership within the company, as it's the leadership's responsibility to stamp down on this sort of behaviour.
“Okay so, the part of the app you’re working on is weeble-wobble which handles transactions. Weeble-wobble interfaces with poopy-leg to create financial reports, and with screaming-kidney to do fraud analysis.”
Maybe this is fine for devops? I mean, if pets, not cattle is the regime within the org
https://www.youtube.com/watch?v=y8OnoxKotPQ
You can name your servers after star trek characters, and routers after star wars characters, only if you have very few.
Regarding naming - Middle Earth should have many possible names at hand.
Which is fine if it's just you. But if it's a company and you hire someone who doesn't rewatch TNG every weekend, then it doesn't help that you know the daud's wife's name.
And that would hurt the business.
I'm sure every character in the star wars cantina has a name. That's not the point.
Sounds like there's a workflow problem around renaming services?
That said, I think a certain degree of whimsy is definitely acceptable (necessary?) in the workplace and should be encouraged. I can support silly names for the sake of having fun. But maybe if it's something important, foundational, try to remember it may not be as fun for someone 5 years down the line at 2AM.
Also, per the article, the problem is that "ServiceRouter" maybe isn't as obvious as you might think. The actual HTTP routing might be done by "HttpPathInspector". "ServiceRouter" is actually a non-core message router for analytics.
Naming is hard.
Another fun story I recall happened when server technician had to replace faulty HDD in RAID array. We ensured that the serial numbers were correct in correspondence yet still technician replaced the wrong one. When we complained we got into funny argument that we should use color code to designate HDD. Serial numbers are hard to pass and easy to confuse (especially since they were next to each other). But color coding wasn't provided to us, customers - we couldn't use it even if we wanted to.
Naming is hard but descriptive name doesn't guarantee correctness or helpfulness just as non-descriptive wont ease understanding or improve communication without proper directory or conceptual mapping. Does DatabaseServer-EU-259-aed6f give more information than "dumpstation" in scenario where it relates to single server wordpress blog.
In the end it's still about difficulty of naming, middle ground and consistence. Ubuntu for years used letter coding with animals and it worked. MacOS uses naming scheme for releases even though iOS and iPadOS are numbered only. Some people would be confused that Windows 95 is after Windows 3.11 and before Windows 10 and Windows 11. Not sure if Docker still use cutesy auto generated names for containers but it was fun to use.
Naming is hard.
What service ? Routing it where? The "descriptive" here isn't describing anything useful.
"OrderBaseket" is descriptive. "sso-portal" is descriptive. "ServiceRouter" just uses few related words to the job. My blog is also "serviceRouter"...
I will switch from descriptive to cute once I’ve reached a certain level of abstraction. That level can best be defined as the level where I will need to start advocating for the idea with other engineers.
A new ssh wrapper for automating access to the manufacturing robots? example.factory.sshtool
A log file parser for extracting text-only errors across multiple robot.log lines into structured error objects? example.factory.logs
A quarter-long project to build a new abstraction over all our thirteen different categories of manufacturing robot we have deployed on site that replaces a bunch of shell scripts written by the former CTO, and then actually replace all those shell scripts with the new thing, with tests? example.factory.duckling
I’d promote it as being named after how ducks imprint on their mother and follow her lead. Kind of a nod to the robots, but also to the former CTO. Cute names can feel a little saccharine but it really helps build advocacy obviously — it’s ultimately a branding / marketing exercise.
If you do that day-in day-out at the level of the ssh tool or the log parser — projects that should ideally have a low level of controversy compared to the shell script rewrite — then people are going to get annoyed with you.
- Oh, _gfuby_ can now monitor my instance in production in addition to being a code versioning system!?
The issues with practical names mentioned in this article are pretty small when compared to the very real issue of understanding cute-named services. If AuthService goes down, I know what that means. If Balthasar goes down, I now have to understand what that is, look up documentation, find the right team, etc.
Firstly when I was a so-called manager cute project names were a nightmare - who could remember what "project mayhem" was - lift and shift half the the data centre or was it refactoring the stupid accounts hack. Project refactor-accounts-monthly-charge is something at exec level everyone can remember. It's fine for project-negotiate-possible-sale-of-dutch-office to be called project mayhem, because powerpoints get acciendetaly shared, emails get read, but there aren't many of those.
Secondly Sam used to be called Sam Smith because he was the smith. If he becomes used for something else people will create a directory (in their heads or in reality). And that's the key here.
Directory services are way easier to manage
What, you don't remember every Star Trek character? What, you can't spell every Greek philosopher?
Really, you don't know which are star names and which are galaxy names?
And then there's the reuse. Which project mayhem is this?