While I don't agree with the author AT ALL. I think products need two names: a marketing name and a code name. I was at a company that kept renaming the marketing name. And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector.
I kept trying to tell people that the marketing name is going to change all the time and that the package we put it under should be very different from the marketing name - on purpose, so that we don't need to repackage it every 2 weeks. Call it com.companyname.dataintegrator. The marketing name of the data integrator can change all day long and its package must remain dataintegrator.
100%. I was at a company and they kept renaming the internal name to match the marketing name. We had 3 names for some older tech and 2 names for the less than a year old service. I strongly recommended that we should adopt the original name as a "codename" and use it for code and internal technical documents.
Marketing should absolutely have full control over the user visible name. But technology has different needs where a "codename" is a much better match. Having two names is generally only a tiny bit confusing.
I have also yet to see a codebase rename that completes before the product name changes again. You always just end up with a confusing slew of N names in the codebase if you try to rename.
IIRC the NS prefix was in use long before there were any dealings with Sun. There was software development going on at NeXT before they had the name for the OS ("NeXTStep"). So, NX for NeXT, NS for NeXTStep.
> And for some reason I couldn't get the programmers to stop spending weeks redoing packages: com.companyname.integrationhub to com.companyname.superconnector.
I wonder how much open offices comingling sales/marketing/engineering has contributed to this kind of dysfunctional crossing the streams.
Would you extend this to all names and not just product? I attempt to push domain driven design and one of the principles is that a single concept should be called by a single name. It all works well until product management decides to unilaterally push renaming of of concept in UI for vague 'market' reasons...
It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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"
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.
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."
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.
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.
Also becomes awkward and distracting having to explain to other peoples’ lawyers (or government officials!) what those cute names represent when things go wrong.
> 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.
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.
If you're going to do this, why not also do it for classes, function, and variables?
The the reasons you wouldn't do that are also reasons you shouldn't do it for services.
A product might have a code and/or marketing name, but that's a different story. You shouldn't give cute names to services or other internal components pieces of products. Every time this comes up I remember that KRAZAM Microservices video, "because Bingo knows everyone's name-o". (https://youtu.be/y8OnoxKotPQ)
A random aside, definitely the very worst name you can give any product is "Atlas". I once worked on a product called "Atlas" that also used a library and an unrelated external API also called "Atlas".
In my opinion, one of the top criteria for a good developer is that they don't fear making changes. If a function has changed purposed, a good programmer will rename that function even if it's across hundreds of files.
A poor programmer will see that as wasted effort and not do it.
From my experience working with a good infrastructure team, good system administrators do the same sort of thing. It's easy to not change names but in 10 years you have no idea what you're looking at. Our team is constantly moving stuff around and renaming things when it makes sense to do it.
To me the most painful style of wasted effort is that of renaming an entity and all of the connection points to other services, and documentation, wikis, slack channel names, email lists, etc. because the name is causing cognitive dissonance.
That's the trade off. You have to decide whether or not it's worth it. But if you never do it, then you end up a with a system where nothing means what it says and that's awful.
I feel the best time to rename something is as early in the development process as possible. Because the longer something is wrong the more entrenched it becomes.
I guess it can be subjective whether the cognitive dissonance isn’t more painful, but it certainly can be a constant strain. This is especially the case if the term in question is a software engineering term you also want to use in its regular meaning. “Cute” names at least avoid that situation.
Are they easy to change? Consider the scenario of a SDK provided to external developers (ex: UIKit). Any symbols made to be public API cannot be changed between releases cannot be changed without breaking clients.
It's true the SDK authors can deprecate and remove symbols, but this is not always easy to do, and sometimes can take several months or years to do.
Public API names aren’t easy to change, for backwards compatibility reasons, but for the same reason you also wouldn’t change their semantics, which is what would trigger a rename.
The exception is when a name is wrong for the semantics from the beginning. In that case, there’s usually the option to deprecate it (make it trigger a warning) and only keep it for compatibility, and add the correct name as an alias next to it.
Broadly, I'd say there are three categories, in ascending order of change difficulty:
1. Private code. Renaming things is easy, since you only have to worry about your own references.
2. Libraries with no external dependencies. Changing symbols in the public API can break clients, but clients can always not upgrade and everything will continue working exactly as before.
3. Libraries with external dependencies, like on an operating system (e.g. UIKit) or a web service. Changing names will break clients that don't also upgrade. IMO this doesn't really count as changing the name in code, per se — the issue isn't that the downstream code is coupled to the library code, per se, but the underlying infrastructure.
It sounds like your deployment and provisioning infrastructure is sub-par. Why would you shove unrelated functionality into the same service? Especially to the point where you can't even choose a descriptive name for said service.
> It sounds like your deployment and provisioning infrastructure is sub-par.
If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.
If you need to choose a random name up front because you can't predict what the service might be doing someday, possibly you have a poor architecture--services should follow scaling and data boundaries, both of which lock you into a specific (namable) scope, or if we are more charitable to you and blame devops instead it takes too much effort to deploy new services, there too many manual steps involved, or you're doing things like hard-coding configuration or references between services, leaving you to shove unrelated functionality into the same services out of expediency.
You could make the exact arguments you're making about classes or modules. You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code. If your infrastructure is not set up to allow services to be changed easily or I think you should stick to a monolithic architecture, because trying to do development in an infrastructure-constrained environment is a nightmare.
I have to admit initially it didn't cross my mind that this could just be bad service design, Service boundaries chosen poorly not because infrastructure makes changes difficult but because developers just didn't know or plan properly, but now that I think about it that is probably the more common case and in fact is another good argument for descriptive names--e.g. hopefully it would give one pause if they decided to add some order processing code into a service named "delivery notification".
> You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code.
Unless you have extremely simple infrastructure, it's very much not "all just code": it's programs that are running on different machines that don't intrinsically know about each other.
Then it becomes a coordination problem. For example, if service B calls service A and you want to change the hostname of service A, you need to first make sure that service A will respond to the new hostname, and then that your discovery layer knows about that change before service B — and also that it still handles the old name correctly until service B has been updated.
"Oh, but I have all my infrastructure in [Terraform/Cloudformation/Pulumi/etc], that's not a problem for me." First of all, there are a ton of reasons things might slip through the cracks. Maybe you're migrating from one system to another, or maybe some dependency doesn't have great support, etc. But second of all, infrastructure is stateful and things can go wrong. If your change fails halfway through for some reason, and only some pieces are aware of the new name, are you sure your system is consistent?
Code, on the other hand, is just code — changes are atomic and self-contained. If I change a function name, I know that everything that could possibly use that function is contained within my codebase. When I deploy, it's either using the new name or not — and it doesn't matter if half of my servers have different names for the function, because they don't interfere with each other.
The one exception to this is public APIs, which are difficult to change without breaking downstream consumers. But consumers can always choose not to upgrade their version of the library. And when they can't — when it's a proxy for an external dependency, like a web service — the issue isn't the name in the code, but the name in the infrastructure.
It's not always possible to know upfront the perfect architecture of your whole system. Not every business domain is as trivial as 'delivery notification'.
If you change "not always" to "almost never", I'd agree with you. I still think you can give your services descriptive names. Even non-trivial domains can have a name.
Anyone building a monolithic application is using packages or sub-modules to organize their code. While basically all monolithic applications have some kind of product or code name, I have never once seen anyone give a sub-module a weird cute name. But deploy that same code into a container and suddenly people want to start calling it "Skywalker" or "Cthulhu".
If you are using Domain Driven Design (or something similar, hopefully you're using some kind of methodology), naming the domain is one of the very first steps. You should be able to come up with a name for a service domain that is descriptive enough such that a major change to the name would also mean it was a different service.
What I am seeing is all the pro-cute names arguments against this seems to be describing a scenario where you're just sort of randomly adding code to services out of convenience. This is very much putting the cart before the horse and I don't really know what else to say beside that if you're doing that I think having cute names is probably the least of your problems, particularly when you're talking about long term maintenance of this software. These names do eventually have to be described to someone, and if you can give a coherent description of what the "Birdman" service does, you should be able to give it a good name.
First and foremost, services should own their own data, therefore it necessarily follows that service boundaries will follow data/domain boundaries. The second most important consideration for service boundaries is scaling points, which in turn directs service boundaries to follow specific interactions. I almost never break up services unless they cross one of these two lines, and taken together they give a scope of data and activity for any service that is enough to give it a descriptive name.
> Why would you shove unrelated functionality into the same service?
Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service.
Then, later, you end up not even using the broadcast functionality.
Code drifts and changes. Top level names are more likely to be lies than variable or function names, because the latter are easy to change.
> Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients.
Looks like you are trying to get a complete separation of concerns. That's a good practice when modularizing code, but it's not unambiguously good for services, because composing services come with added cost.
On practice that means that if those pieces of information are really important, there will probably exist many services that read them, and trying to reduce that to a single one will break many good qualities your software has elsewhere. Your service having a clear purpose is one of those qualities.
“The name doesn’t reflect its function anymore” is not a good case for “let’s name it some random thing”, and certainly not a good case for “let’s arbitrarily give descriptive names for some resources over others”
It's very difficult to change service names, given that you have a large population of people conditioned to say the name and lots of documentation artifacts, other code, etc.
"Broadcast message service" is, as the author points out, way too generic and also too long to be used freely. "Scattershot" rolls off the tongue and won't be completely wrong if functionality changes. And hopefully we have a small enough quorum of services that we don't drown in jargon.
Surely though in any case either there is some unified theme or purpose for a service or you are building a monolithic application which can just have the same name as the product.
If you are putting random functions into a service to the point where you can't even pick a descriptive name, that sounds like you've got bigger problems.
You can expose multiple things with each having their own name, and still have it implemented within a single service (single unit of deployment). The clients however don’t have to depend on it being a single service; it can appear as separate services to them. That way the scope of the “all in one” service name remains limited, and can therefore also be more easily changed.
This is similar to running multiple services on the same host, but clients don’t use the canonical hostname, but service-specific subdomain names.
so true, names in different contexts have different needs. For internal stuff comprehension is king. I see this show up in front end and backend stuff frequently, especially in the microcosm of a console app in python where argparser can specify the `dest`, or internal name of a command line option. All my bool options get dest=is_xxx prefixes. Using more verbose names under dest is good too.
Back in the day we used cutesy names for boxes, and we did it for good reason:
Back then, before cloud services, when you were building out an application, you would build one computer, load it up with some services, and then when that one started performing poorly you’d add another computer and move some of the services off.
You would frequently rebalance which services went on which box, in order to maximize performance.
But these boxes weren’t services themselves, they were just the machine some set of services happened to run on.
So we gave them cute names because the hardware was largely meaningless. They had no inherent purpose, so we named them Athena, Zeus, etc so we had something to remember.
These names were largely not used for the services. Maybe you did have your FTP service on Athena, and maybe that was the only service on there. You still served it from ftp.techdazzle.com or whatever.
I feel like people just ported this concept forward into the microservices realm because it’s fun, even though it doesn’t really make as much sense in a cloud environment.
A funny example of this can be found by looking for nameserver entries for vatican.va. An apostle and arch-angel for the Vatican, mixed with an Egyptian god and apocryphal character for the Roma exchange they partner with.
vatican.va. 3600 IN NS john.vatican.va.
vatican.va. 3600 IN NS michael.vatican.va.
vatican.va. 3600 IN NS seth.namex.it.
vatican.va. 3600 IN NS osiris.namex.it.
Even more fundamental, if you had multiple computers and needed to network them up, they required a name to be referenced by. Computers on the same network ended up with names from a common theme.
My first role had machines like: ob-la-di for the reporting services server, ob-la-da for the nightly build server, etc. I always hated it. In aggregate the services on these servers belonged together. The sysadmin was just extremely casual about his role and thought it was funny and cute. I eventually got sick of going to the wrong server all of the time and mapped them more logically in my hosts file. It's not like he couldn't have done this originally or eventually, but well into the 2010s he was using song titles for server names.
Ah, memories.
Remember the time a new set of boxes came, and my and a collegue came up with a bunch of names. Being a physics department, the new names had to fit in the existing name convention with names like Gauss and Planck. And yes, used that to get the latter one placed on my desk (new shiny powerpc with colour screen!) instead of an old Atari;-)
The vast majority of IPC already used sockets decades ago, so it was easy to split a composition of services across multiple machines (just change the config from unix domain- to network sockets). Anything that ran commands to do things could be wrapped in ssh (for example, that's how I offloaded image processing for a sharing site).
Two layers of DNS records solve the addressing issue: each box gets a static codename with an A record and each service gets a descriptive name with a CNAME record pointing at the box it's on.
When you move a service, change the CNAME to point to the new box. If you have full box replicas/backups, you can also switch the box name or reroute at the IP level. Preferably you're running your own DNS and can issue a flush command to your entire fleet so you're not stuck waiting for propagation.
Yeah, CORBA / RMI which microservices eschewed for HTTP.
I had a joke years ago that the reason HTTP services became so popular was simply because those ports were the only ones open in the firewall, so people used those rather than having to get new ports approved by some convoluted security review.
You're optimizing for the wrong things and working with an artificially limited set of constraints.
The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day.
Further, you're introducing unnecessary, artificial constraints. If you need to add new responsibilities to a service that don't fit with in it's existing scope - the correct answer is to make a new service.
Granted, some times we don't have time for either a rename or a new service and we have to duct tape the functionality wherever we can. This is called techdebt. It should be documented, tracked, and paid down at a later date... By renaming the service or refactoring out a new one.
Attaching arbitrary functionality on to cutely named services that don't have logical coherence is not future proofing. It's really bad software design.
> The rule of thumb is that we spend 10x the amount of time reading code that we do writing it. When you use cute names to avoid the pain of name changes when the service changes, you're optimizing for writing over reading. It's a mistake. You pay the cost of a name change once, but you pay the cost of an unclear name many, many times per day.
That is for name of variable. Changing a name of whole application can be royal PITA all over the stack, if the "one time change" is "scour every documentation ever produced and change the name there too so people won't get confused.
And not just docs, put the name of service as query in Grafana ? Gotta go around dashboards changing that too
This is good advice in the small, but I think the author is correct for larger services. I can't tell you how many times someone insisted on a name that was "universal such and such" which, uh, turned out not to be universal.
More concretely, this is good advice for services that you expect many teams to hook into, and not great advice for services that you think should not expand 1-3 teams ever.
I think the problem you're speaking to has more to do with attempts at "universal" design. Which actually runs counter to the principal that services should have a limited, clearly defined set of responsibilities.
I made an account on HN because this is the worst post I have ever read here.
NO!!!! DON'T USE CUTE NAMES!!!
I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Zanik on the Bremmis platform to include the Mumana-Service to distribute the app.
What? It doesn't work? That's because you didn't integrate the Jonhson-Rod stupid? How is it supposed to work without the Johnson-Rod? Are you even a real programmer?
Would this be easier if you needed to integrate with user-provider-service, timestamp-conversion-service, image-storage-service (which also stores videos these days, though HEIFF and h.265 has obviously been moved to iOS-image-storage-service so customers can be billed for the special software that requires patents) to upload a signed SecuredApplicationPackage file to InternalExternalSoftwareManager so that it can be included in the application_distributor next time ReleaseMgr decides to update its endpoints?
What, you forgot to integrate with the SecondaryDataValidationService? How is it supposed to work without SecondaryDataValidationService? Are you even a real programmer?
God forbid you use the old DataValidationService or ReplacementDataValidationService, those have been deprecated for years. And you don't want to make a fool of yourself by using ImageStore instead of image-storage-service, ImageStore is clearly for operating system images not pictures! And what are you doing touching IntermediateDataLayer? That's only for enterprise customers, shouldn't that be obvious? It'd like adding a dependency to CachingLayerV2 to a ServerSideSoftware deployment package, simply ridiculous!
If you have a forest of microservices to browse through, it doesn't matter if they're named after pokemon or if some engineer came up with a descriptive name. You need a guide either way, because half of the services that sound like they may be relevant do something completely irrelevant or have been put in maintenance only mode years ago anyway.
Not only that, but half of those services would become acronyms very quickly.
Would this be easier if you needed to integrate with UPS, TCS, ISS (which also stores videos these days, though HEIFF and h.265 has obviously been moved to iOS-ISS so customers can be billed for the special software that requires patents) to upload a signed SAP file to IESM so that it can be included in the AD next time RM decides to update its endpoints?
Yes that would absolutely be easier - I don't understand why this is controversial?
If you have a bunch of services, some of which are relevant, some are not, and domain knowledge is required to understand which to use at which times, then that problem exists independently of their names, as you say. Naming them after Pokemon obviously makes it more difficult to learn which is which; how can it not?
We use pretty much random names for our servers and other hardware, but all of that is abstracted so during normal operation you don't even know what thing you are using unless you want to for some reason.
I am not really for or against using names instead of numbers or whatever, because I should never even need to care if things are done right.
Right? It's like having to "google" to find out how to use your "apple" to interface with "postgres" that's running on "linux"! It should be "global-web-searcher-1", "computer-vendor-17", "database-18" and "open-source-operating-system-derived-from-another-operating-system"!
Exactly! That's why I always advocate giving every monitor in an office its own unique name (mine is Moe!) and every keyboard, chair, desk, etc. Who wants to use those stuffy descriptive generic names??
Obviously trademarks and other product names are more useful if they're unique; Google, Apple, etc. are not components of a system, they're products. It's like getting your car fixed - they don't tell you the Jane and the two front Turnipheads need replacing, now do they?
Nope - we already have widely understood descriptive nouns for those things. If I walk into an office and someone asks me to bring a chair over, I know instantly what they're talking about. They might need to qualify it - that blue, high-backed chair with the arms, for example - but if they said 'bring Clive over', I'd be stuck until I learned the (fun!) names of the office chairs, and would likely be confused for a long time until I managed to remember who was who, not to mention that there would be no other incentive to learn those names as that information has no value outside the office. This is the point at issue here.
We also have widely understood descriptive nouns in software development - for example if I hand you a class called 'xyz-repository', you probably know instantly that it's a class designed to manage the lifetime of xyz objects that are persisted to and retrieved from a database. If we had an identity service we could choose to call it:
a) login-and-token-management-service, per your example; unnecessarily wordy but obvious
b) identity-service
c) gatekeeper, which is fanciful but at least slightly descriptive; we'd probably be able to guess its purpose from the name
d) dr-octopus, which is lots of fun and completely useless for helping me to remember what it does
Hopefully you can see that b) is the most boring but most widely understandably name; if b) is not an option because we've invented a new thing that doesn't have a descriptive noun, then a) is still the best choice of the remaining three as it tells everyone what it does without requiring any inside knowledge.
It's about cognitive load - some DSLs add value, others just increase the amount of mental effort required to understand the system.
The only services that continue to live have memorable, marketable names that stick in people's heads and make them want to say the service because of the cheap dopamine hit they get from being "in-the-know".
The ones that no longer exist were purely utilitarian, but since their identity was pure functionality they are only known as their bugs and quickly despised?
---
I don't know if this is true. Just asking the question.
No they’re not. People just aren’t determined or organized.
> It's impossible to predict with certainty how your software's requirements will evolve over time.
You don’t need to predict it. You evolve things as needed, including names of components of the system.
The idea that you need to pick a generic name because you don’t want to specify exactly what a service does and instead want to change responsibility constantly without change its name is weird.
> And then the cherry on top, the final nail in the coffin of descriptive names: They're just too hard to say and remember, and they're no fun.
Why are software engineers like this? My idea of fun is not simply calling things Magneto and Cyclops, or Potter or Dumbledore, or Denali and Everest, or Wham and Bam, or whatever else. You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities. The amount of stress coming from things going in the opposite direction makes people’s lives much less fun.
I know software engineers like to blame management for all their problems, but I have come to the general conclusion that software engineers cause their own problems.
I’ve worked at companies that name things like this (sadly, it’s most companies), and you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed. By not needing to change the name because it’s not descriptive, it naturally starts to become a catch all monolith because one has removed all friction to not doing so. You end up with the situation of not being able to say “Startrooper does <x>” because it doesn’t just do <x>. It does a million other things because “Startrooper is where we put things because we don’t want to create a new component or service”.
> you can work there for months before you know what <cutesy name> does. It’s because it’s generic and because a “fun” name was chosen, its responsibilities have not only changed but its number of responsibilities have changed
Excellent insight! If you use cutesy names, the intent of the component will get muddled and responsibilities will be strewn about. I've never seen an exception. Your components become a fuzzy set of containers into which all ideas are tossed without any design intent.
The only way I've seen to avoid this is to develop your own taxonomy/dictionary defining what all the cutesy names mean, what their interfaces/boundaries should be, etc. At that point, consider how much time you've wasted building and training your team on a bespoke vocabulary ... why not just encode the meaning into the name itself? Precise naming leads to better design and most importantly, encourages future developers to actually following that design.
It seems these cutesy type names are more representations of proprietary code than open source modules. The name becomes opaque to its internals.
I noticed when I switched form MS Windows to Linux, there was a marked difference in the names of tools and modules. So, you could get a better high-level understanding for how it works. With Windows, the solution was more than likely strictly prescriptive. But with an open source design, it becomes much easier to grok the whole setup. Not sure if this is entirely do to naming conventions. It might also have to do with the online communities.
> No they’re not. People just aren’t determined or organized.
This is very untrue.
Many moons ago my company changed its name, and we still have the old name lingering around in stupid places. There are e.g. several third-party services which simply won't let us change the name and carry our data forward, or where proper migration would take eng-months.
I guess you could say we're "not determined enough" (pause development! take the data loss!) but it just doesn't make business sense to pursue it.
There are quite a few of these. Jenkins has "Hudson" in its internal namespaces. Various Microsoft products have their old names in classes. Once a name is used externally, it doesn't matter how organized you are, there are uses outwith your control.
Software names and component names can be really hard to change though, especially because those names tend to leak into the public API.
When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++ or Java or other namespace, executable file name for scripting, etc.).
So yes, software service and component names are hard to change when customers start relying on them.
So why not rename versions to cutesy names then? Function names? Argument names? That way, you never have to rename anything and can just change the behavior.
Sorry for the wall of text. I found your question super valuable for crystallizing my thoughts. TL;DR: Abstract names are good when your scope is poorly defined and hopefully your functions aren't like that. If they are, maybe consider abstract names for them.
The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want.
Why not use abstract names at smaller scales? I can come up with a couple of reasons:
First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;).
Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply.
Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name.
Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.
The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.
> The name gets repeated in so many places if it's important.
like the parent points out, the named thing is likely "important" precisely because it had a non-descriptive name to begin with and engineers added things to it they shouldn't have
if it had a descriptive name then other functionality would've been put in their own module
See my other comment in another reply, but are you suggesting that it's better for something to keep the same name while also changing its behavior and purpose? It doesn't make any sense.
In a large enough project, this sometimes results in pull requests covering hundreds of files. While the renaming itself may be a simple task, getting multiple reviews takes a lot of effort and management may have other priorities.
I have renamed a large-ish service that was integral to the whole system before. For one, it wasn't that hard. And secondly, it usually reveals some existing issues and architectural deficiencies.
By doing this your names aren't in 1NF and you're making it harder than needed to do updates. If your names are cute/unique then changing, expanding, or reducing service responsibilities just means updating the single document that says what Dreki does.
I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather focus on the function when trying to name something. It will do you no good if something is called `MyCompanyCart` when it instead could have just been called `Cart`. Most of all, don't include the name of the company in the codebase, especially as variable names, and double especially in data definitions.
The problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market.
The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”.
It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier to find and talk about than K297400!
Sure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?
Namespacing can exist in more ways than just in code. Surely you could have your server, renderer, and storage components in one repository under the Ads product:
Vermeer Technologies still linger in Microsoft 365. I think they were acquired in the 90s and their product became Frontpage, which became SharePoint. A bunch of critical services lives in _vti_bin
Another example is Discord. In the beginning Discord servers were called Guilds and that's still their name in all their documentation and APIs. So it's more than company names.
Discord is a... indecent woman to work with, if you want to build a bot once so that it works for any longer period of time... you need to wake up, because that's sadly not how it works.
I have no idea what you're talking about but Discord has got to be one of the most pleasant bot development experiences that exists. Their shit is really well architected and their API handles so much lifting for you.
I get that some people were burned by the switch from "free-for-all text bots" to structured bots with OAuth but the new way is so so so much better.
Agreed. People may not be determined enough and that's fine because not every cause is worth determination.
I say this each time someone wants to rename something for social justice reasons. Renaming is a lot of hussle, and if you decide to go for it you better know what exactly it is that you're buying with it.
I utterly disagree with you. After 30+ years of doing this, I almost always despise "descriptive names" - they are almost always wrong, generic, and hard to say/type. They are difficult to change, and even if you do change them, you just end up with another crappy descriptive name. "database-writer" or "user-database-writer" or "database-post-writer" or "event-logger" or "event-logger-2". While every once in a while you'll encounter a descriptive name that lets you actually know what it does and doesn't change over time, the vast majority of the time that name is still hard to write/say and so people use initials which makes the descriptive name pointless.
Use a non-descriptive name, because you can't tell what a service/app does by just the name. People say "google" not "global-web-searcher". You can't tell what a service really does by just the name, so stop trying.
Descriptive names can still be bad. Cute names have no chance of being useful. Someone else pointed it out or alluded to it, but I suppose there is a gradient of abstraction. The level of abstraction, from product to service to component to module to function to variable names, probably determines some allowance in how generic the name can be, from more generic to less generic, respectively.
Are the names Amazon, Google, Facebook, Kleenex, Q-Tip, Thermos, Yo-Yo, or Zipper useful? They're all cute names and I'm positive most people could tell you what each of these things do. How is that not useful?
I too have been doing this for decades and I completely disagree with you. The vast majority of names I see are mostly correct, with the exceptions representing the areas with most technical debt. It is far easier to remember the handful of services with bad names do than to have to remember the mappings for every piece of functionality. If there's an order service, it's pretty good bet it will process orders. If there's a search service, it probably does something with search. Does it also do billing? Maybe. Then that's one I'll just have to remember. But it's way easier to remember "some bonehead put billing in the orders service" than "orders and billings is snowwhite, search is sneezy...or was that dopey?" And if you have an orders service that doesn't do orders...well, there's clearly some very bad technical debt in that area. That's worth knowing too.
Exactly. Being descriptive is how you get a service that does something completely unrelated to its name, later on. Or worse, you end up with 2 services with similar names that do similar things, and users aren’t sure why there are 2, but just know which one they like.
I think there is a happy medium. I think you can have a cutsey name that gently suggests what the service is responsible for.
I don't fully know what task-service does, I don't know how it differs from scheduled-task-service-v2. In the same way I don't know what starship does or how its different from rocketship.
But I can probably guess and easily remember what 'automated-task-scheduler' or 'The Taskinator' does.
I don't think it has to be an all-or-none thing. A well thought out cutsey name can be just as effective as a well thought out descriptive name. The issue is when the names are picked lazily or at random IMO.
I agree with there’s a middle ground, especially depending on what level you are in the stack. However, I would consider those examples you gave to be descriptive and certainly not overly cutesy or fun.
> No they’re not. People just aren’t determined or organized.
You just provided your own counterargument. People naturally aren't determined or organized, that's why names are hard to change.
You can't change human nature, you can only work around it, and cute names are a solution for that. Cute names work even if people are disorganized, and they are. Furthermore, cute name, rather than purely generic or descriptive names evoke emotions, making them more memorable, another human thing.
> You can't change human nature, you can only work around it
Yes you can. When a person becomes a civil engineer they are trained to change their nature so that when they design a bridge they do it in a way that meets all the standards with full documentation rather than the way they would sloppily design their dogshed at home.
But isn't that exactly the "work around it" part? There are full standards one needs to adhere to, so you basically work around the sloppy part of human nature.
Exactly - engineers don't change their nature, they're legally mandated to follow very strict rules regarding best practices. They work in heavily constrained systems with checks and balances to prevent slip-ups. If they don't follow the rules and something goes wrong they're legally liable.
Strip away the systems that coerce engineers into complying with best practices and you'll very quickly see how little their "nature" has changed from the average person's.
This "cute names" pattern is simply a system to prevent some possible bad outcomes of developers free-styling. Whether it's worth the tradeoffs is debatable, but feeble systems like this are all we've got unless we establish regulatory bodies like those in "real" engineering.
The millions of programmers in the world aren't going to all magically develop discipline - software engineering necessarily requires building your systems with that lack of discipline in mind.
Software development seems much more opposed to standardization than traditional engineering disciplines. I don't know if it's an artifact of software development itself (e.g., things are just so easy to change by comparison that it becomes hard to set a standard because things move so fast) or if its an artifact of software being a much newer discipline than others. E.g., when you look at mechanical designs from the early industrial age, it becomes pretty clear there were no standards then either.
>You can't change human nature, you can only work around it
You can create systems that provide the guardrails and incentives to modify human behavior though.
The root of much of this discussion is communication, which is a near-ubiquitous problem in relatively large organizations. Communication, in this instance, is that people want to have a clue about what something does.
The authors point is that as code changes, the names may no longer communicate what that code does. Unfortunately, their suggestion to make cutesy names does nothing to fix the communication issue. We're still left with poor communication about what the thing does. It's a veiled attempted to pretend like they're solving the problem of communication, but it's just a disguise that leaves the same problem at the end of the day.
At least with descriptive names, I can have some clue as to what the code used to do, and maybe glean from that why it is the way it is now.
> You know what is fun when it comes to work? Things that work, are named appropriately, are understandable, and people not needing trivialities
I don’t know I agree with this. Microsoft has taken the descriptive naming style all the way down to products. Not only names like Batch or Functions don’t add much value, but also it makes searching information about them much harder than “cute” names (such as Excel).
I also think we tend to overthink this too much. In the end, the significance of names is as high as choosing between tabs or spaces.
This really seems to have started at Apple and has been copied by both Microsoft and Gnome. I don't have any UX expectations for MS [1], but in Gnome it's irritating because most Gnome applications don't display their real name anywhere in the UI any more, so you have to Google what the binary and package names are etc.
[1] I tried to open calculator on a Windows 10 box and it doesn't work any more, even launching calc.exe directly just gives a weird error message that "I need a new app for opening this ms-calculator:// link". Wat.
Haha, I am not picking sides but I recently saw a suggestion to move a service's DNS records from Cloud DNS to Cloud DNS. One was GCP and the other some smaller provider.
For the big cloud providers, I've definitely seen people struggle with the names. Is it Google Compute Engine or Google Cloud Engine? Which one is which of Google Cloud Run and Google Compute Engine? Amazon Route 53? Route 57? 35?
I guess the bigger the service the more creative name it should have?
> Microsoft has taken the descriptive naming style all the way down to products
May be more on the "Developer Products" side, but this is exactly how I feel about PowerShell cmdlets... Did PowerShell's developer team dislike Linux's software/package/scripting ecosystem so much that they had to make two-word long capitalized command names a good practice?
> Not only names like Batch or Functions don’t add much value
overly vague names have the same problems cute names have, and you generally see the same type of people using them (those who think software is "hard to change"–you're thinking of hardware!)
countless codebases have something called "entity" some geezer wrote a million years ago that the only reason it hasn't been deleted is that it's so generic everything depends on it
Modern generic-ass naming schemes are absolutely infuriating. I hear someone say "oh yeah, it's been easier since we moved our Bluē processes into Laundr containers which we manage through a mix of Bicycle and Parakeet" and my lungs are not big enough for the sigh I want to emit.
And then you look up the Bluē website and it just says "revolutionize your business by streamlining Laundr workflow!" and the Laundr website describes it as "flexible double-acting hypercraft for Parakeet ecosystems" and the Bicycle website just says "Bicycle" with a giant picture of a fixed-speed bike.
(I'm assuming you made all these names up but honestly I can't even tell any more.)
They all have a "know more" session with a video (it doesn't tell anything more), a huge set of companies that use them, and a link to the documentation, where you can find a diagram with arrows pointing all over Laundr, Bluẽ, Bicycle and Parakeet.
If you insist on the docs, there are installation instructions (use Docker) and something that looks like an API. But it's not clear even if you must use the API to interact with the thing, or if it's the development docs.
Is there some kind of consultancy doing those sites?
They should name themselves clearly for the situations in which they offer compelling performance advantages. If that’s an issue then maybe they don’t deserve names.
> You end up with the situation of not being able to say “Startrooper does <x>” because it doesn’t just do <x>.
And this leads to all the dysfunctions software engineers are supposed to care about protecting against. If a system has no high-level invariants, it is an organically evolved hairball that only a small number of Gurus, typically the people who oversaw the entire multi-year evolution of the hairball, understand or care to understand. This sets you up perfectly for endless Lava Anti-Pattern hell: only a Guru can change the system. For everyone else, the system can never be changed, only added to.
That said, point taken from the other comments saying how names can be hard to change due to external constraints. Maybe the name matters less than the discipline to make sure that "Startrooper does X and only X". Internal documentation should attempt to thoughtfully name or concisely describe the functionality of something, and if it's not possible to do so, that suggests that the system does not follow modularity best practices.
> No they’re not. People just aren’t determined or organized.
I think this point from the article gets to the harder part.
> Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization.
Technical modifications to change a name are one thing. Once people are stuck with using a particular name, it can be hard to change that.
It's worse than that - the name is a brand so develops value in its own right. It's not just hard to change the name in peoples' minds, it's downright damaging (unless your product was crap, in which case changing the name might be a good strategy).
Right, there are cases at work where users are like "Foo doesn't work" and you have no idea what Foo is, and turns out the users call it Foo because that was the name of an in-house service 15 years ago which did roughly the same thing, then we switched to Cloud Bar, and actually a few years ago Cloud Bar went on Our Incredible Journey https://ourincrediblejourney.tumblr.com/ so we built a new in-house service Baz, which mimics most of what Cloud Bar did, yet the users still call it Foo even if they weren't here 15 years ago, that's what the person who taught them called it. You need to investigate a problem in Baz, even though the user said Foo, if you like you can tell them it's Baz as well, but like when teenagers correct their parents about teen slang it's not likely to have much real effect.
And you might say, "Descriptive names would fix that". No they wouldn't. The user thinks Foo is a Wibbler Manager, if you called it "Wibbler Manager" they'd agree that's descriptive - but actually managing wibblers is trivial, its main purpose is to stop them from mis-managing the wibblers by providing detailed Doop-de-doop so they stop messing about with the wibblers when they're perfectly fine. Which means the Cloud product it got replaced by isn't really "managing wibblers" at all, it's a Doop-de-doop viewer. Except whoops, nobody makes a cloud Doop-de-doop viewer, so it's actually a Thingy viewer, and there's a shim turning Doop-de-doop into Thingy. When this gets in-housed again, chances are the in-house replacement still just handles Thingy. So in terms of description the user thinks their problem is with the Wibbler Manager, but it's actually the Thingy Viewer... we're no better off, you still need somebody to tell you what the hell the users are talking about.
Names are what people call things, it is rude to call people by a name they don't like. But inanimate objects don't have feelings, so you should just call them whatever you want. Emperor Norton Bridge is a better name than "Bay Bridge".
Cute names are fun for the people creating them and writing code. They are stressful for the people trying to make sense of code and maintain a product under a deadline. The question is, which matters more:
A. Having fun yourself over the course of a week.
B. Getting a job done and helping your coworkers get their job done over the course of years.
So many software "engineers" think their job is to make writing their code easier rather than to make reading it easier by the rest of the company. Presumably they think that the faster they write code, the better they are as engineers, and then they add "fighting fires" type skills to their repertoire for all the bugs they contribute to by making code opaque to everyone else.
Prevent fires, take time writing good code, your (current and future) coworkers and customers will thank you.
And if we're talking years, B probably involves yourself too as you are likely to forget what the least memorable even "cute" names are associated with.
Names are super hard to change. They end up everywhere, service directories, URLS, DNS, infrastructure, package names…
It might take a months of work to change a name, just to fix the name of a service which is no longer accurate.
Instead most companies will say something like “that is the translation-service, it is 10 years old. It doesn’t translate anything anymore, but provides load balancing and Auth”
I could not agree more... with you. On top of that, good luck onboarding new recruits or people that move departments.... Cute names are just like abbreviations, they are jargon and are an unnecessary hurdle to become effective.
I agree with you. The cutesy names also derail a lot of conversations if you try to explain key points of your architecture to non-technical users (eg doing a high level RCA after a major outage with management).
I feel you here, amount of non-descriptive stuff inside cold imperative spaghetti is now really impressive across companies, I can't really call something like this a system but a nailed coffin for the business. Only with solid experience comes the knowledge that you need to express you mind-train as simple as possible to understand from first glance and your migraines will go away
TFA is based on a false dichotomy. You can have both.
At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system.
In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locations" containing "pickpockets" that pulled things out of (and put things back into) the hero's "inventory".
This cute-but-descriptive vocabulary really helped less technical people grasp how it all fit together -- even if it was a complete lie and gave the wrong picture of how the system worked under the hood.
(In particular, it is a common misconception that the heroes are driving the action by choosing locations to go to, when in fact it is the locations (processing nodes) that pull heroes (event data) along. But that misunderstanding never caused a problem in the four-ish years I worked with the system.)
You write software formulas (packaging scripts) into bottles (binary packages) in your Cellar (installed packages directory). Some software, such as GUI applications, uses casks, because casks are a different type of container. If you want a new source of packages, you add a tap.
I would take packages, packaging scripts, package repository, binary packages and GUI packages any day over brew's attempt at cutesy terminology.
I think there could be a difference here: you're already familiar with the domain brew operates in.
The system I'm speaking of were extensively used and configured by people who had no prior experience with event-driven, branching logic, nor any familiarity with the terms involved.
You can still argue it would have been more efficient to teach them that domain first, then teach them this particular system for it. Maybe. I'm saying as far as I can tell, there was no drawback to the cutesy terminology for the intended users (nor for developers other than in isolated cases) and it seems to me they learned quicker with that framing than without it.
I agree -- that's exactly what I was saying. The target audience of brew is more likely to be familiar with package management than alcohol brewing, so the choice of terminology was poor. On the other hand, the target audience of the system I was discussing is more likely to be familiar with a fantasy-like narrative than an event loop, so the choice of terminology was beneficial.
This describes absolutely nothing to me. It just confuses and excludes me. Then if and when I understand what it means I then have constantly translate mentally between the cute-yet-infuriating names and their actual meaning in the context.
Along similar lines, we had a hell of a time getting various product people to understand template strings for translations. Eventually I got the idea to just call them "madlibs" and all of them understood it immediately.
This is a great anecdote. I'm firmly on the "call things what they are" side of this debate, but this example shows a thorough domain design that was cleverly shifted to a narrative format. Impressive.
> Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.
But that's just your perspective. At HogCorp Sam is the Senior Data Engineer. People that need data adjustments probably go to the Senior Data Engineer, whether that is Sam or not. If Sam becomes VP of Accounts and is no longer the Senior Data Engineer, people won't stop going to the Senior Data Engineer, but it won't be Sam anymore.
Mmm, you'd be surprised. If Sam becomes VP of Accounts, people will still try to go to him for their data engineering needs, unless he tells them off...
I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go.
You can even name your products with generic descriptive names, if your company's name is unique enough, then that'll act as a namespace for product with generic names. Think of packages in Java, C#, we don't debate about that we have to use a cute name for a X.java or X.CS, because that problem has already been solved by namespaces.
Product name Excel and Office works for Microsoft because that "Microsoft" acts as namespace and "Microsoft Office" and "Microsoft Excel" are unique enough to be fully qualified names.
IMO there is a middle ground: larger & long living services that are internal only, and you have 1-2 handful of them. At my current employer I've started with greek gods whose background is related with the service we're building. E.g. Apollo = god of truth = data warehouse; Hermes = messenger god = messaging service for reporting, etc. It's quite successful in that these names are more quickly adopted and recognized by internal business users, compared to giving it a boring functional name. It also clearly outlines that they are part of a wider concept (new tech stack = greek gods, legacy marked for decommissioning = mostly everything else they hear).
The issue is, if you create an internal tool that allows you to order printer paper for your departments printer you might name it "PaperSupplier": https://papersupplier.acme.com. If it doesn't work, just send a mail to papersupplier@acme.com!
And it works so well, the company now also wants employees to order staples and hole punchers through it.
What do you do now?
Are you going to rename the tool, change the address, change the e-mail?
My strategy would be to go for very generic names: even though it (initially) only allows you to order paper, name it "Internal Supply Portal" or something.
You are right that function may evolve over time and name may not be completely accurate but it's still partially accurate opposed to being being completely inaccurate. In your example papersupplier, I would want to create a new site for staples or better create a new site for all categories of stationary instead of modifying the old one.
I like the idea of having a generic but still descriptive name.
Surely there is some middle ground? Why everything has to be black or white and everyone needs to give silver bullet rules?
A service that stores something can be called "catalog" and it is descriptive, short and memorable. On the other hand, a service that does too many things can be called "zeus" or "cyclops" or whatever and that's okay too. It's difficult to have memorable and short names when things do too many things, or as mentioned in the post, they might change responsibilities.
Also, when you have something descriptive composed of multiple words (like "data-streaming-analyzer") people will certainly start using acronyms (DSA) and then you're back to short names than don't mean anything.
There's a world where everything is not called "pikachu", "cyclops", "potter" and "tortilla", nor "main-store-red-website", "download-analytics-store-and-processing", "sells-stream-processor". Use both. They are both useful!
I feel it's helpful to distinguish between "applications" and the "services" that make up those applications.
- application name: not descriptive unless you are 100% sure scope will not change over time (e.g. a specific report mandated by a regulator); exception to the rule: I actually like using initialisms because they start off descriptive but then over time people use the initialisms exclusively and its almost like you invented a non-descriptive word without the initial confusion
- service names: start with a monolith that is just the application name (or suffix "Core"), only split into other services once you have a good reason, and scope is clear, and then give it a descriptive name
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.)
The renaming point is actually the great point in this article IMO. But this just tells me that languages, platforms, frameworks and editors need to improve so that renaming things is easier. Or that people need to learn how to use grep/sed better (ETA: and use monorepos)…
But this:
> they're no fun
> it won't be fun
is the bane of my existence as someone who tries to get shit done. If this is the lens through which you view software development, and I have to work with you at my job, I literally hate you.
So basically descriptive names might eventually become non-descriptive, or loosely connected. "Cute" names are ALWAYS non-descriptive or loosely connected though. So at worst, a descriptive name eventually becomes as bad as a cutesy name.
Given my experience being onboarded onto legacy code, and bringing others up to speed on my team's code, I'd much rather have names help coders understand the systems 9/10 times as opposed to 0/10 times
> descriptive names might eventually become non-descriptive
It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.
This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp R&D, just because something is named DescriptiveThingThatDoesXYZ, doesn't mean it actually does XYZ.
So now they have to verify what a given class or method does every time. Which means you have the same problem that cutesy names cause (the non-trivial effort of looking stuff up) plus the lack of trust that is now engendered in your engineering org.
To be clear, I think I still fall more towards the "use descriptive names" camp. As another commenter has said, by making it easier to add responsibilities to a certain class or service, the "use cute names" camp promotes the creation of God objects that take on too many responsibilities. But man I hate it when a class's name is actively misleading.
I suppose. But even though I've definitely dealt with poorly-named microservices in my career, I can't really say as I've come across many that stuck out to me as being especially misleading, and not to the point where it was really an issue
> if you find that something has drifted to the point of being misleading, then rename it
Sure, this is the proper course of action when that is an option, but...
> it's software not hardware
...if the "software" is a 3rd-party library that external stakeholders are consuming, then it may as well be hardware, because those class and method names represent an API contract that the library's users expect to remain consistent. Which means changing them involves a non-trivial change management and versioning process. Even when the code is internally-facing only, in a large enough codebase it's often the case that multiple teams (and their respective codebases) depend on those names, increasing the complexity of a rename.
> or comment on code reviews that change the functionality to the point where this is a problem
Again, this is the right move if it's available to you. We don't always have that luxury if the names have already gone off-course by the time we first encounter them. Which is often the case an an older codebase that has been written and re-written by many employees who have come and gone over time.
Again, I continue to believe that I'm a member of the "do NOT use cute names" camp. But I'm seeing a lot of cavalierness in these comments about "just rename it, what's the big deal?" and experience tells me that it's not always that easy.
>It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing.
My God... You don't mean to tell me you actually object to having to read code and figuring out what it does in the grand scheme of things?
I swear, everyone wants to be a writer, but no one wants to read and understand.
Not only is your comment needlessly snarky, but it also mis-characterizes what I said. Show me where in my comment I said that I "object to reading code and figuring out what it does in the grand scheme of things".
What I "object to" is not being able to trust that a class or method does what it says on the tin. I don't think that's unreasonable. I'm fine with reading code in order to understand how something works. I don't want to have to read code in order to verify that it does what it promises. See the difference?
You shouldn’t have to read code to understand architecture. But I have had so many conversations like “this is the Auth-service, it also loadbalances and stores a bunch of state, oh and doesn’t do Auth anymore”. Then the name becomes actively harmful to understanding the system.
A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing".
I could live with funny+descriptive, but for all that is good, funny only just does not work.
the average tenure for software engineers at most companies is two years, so yes
it's not just onboarding, a newer/more junior engineer is much more likely to misunderstand something and introduce a bug if specific context is required to understand the code
As an example of the author's idea in practice, imagine a car, where every part in the car had a cute name, and every car in the world had different cute names. Now imagine being a mechanic. Or going to work for a new car company. Or just being in analytics and trying to understand how to work with the product. Or being a customer trying to understand how your new car works.
A part named after its technical role/purpose shouldn't need to be renamed. If its purpose has changed, you have a different service. Without renaming it, are you talking about OLD cutename, or NEW cutename? Or NEW-NEW cutename? Major version numbers help here, for any kind of name.
Sometimes names are too generic, like "web", or "auth". New services can be named something more specific to be more distinct.
Things named after parts of the organization always get renamed, so always avoid that. No team names, org names, business specific monikers, etc.
And the whole idea of code-as-docs is that your code is descriptive enough that you don't need to pepper tons of comments through the code to understand what it's doing. The same can be applied to architectural components like service and server names.
But you know what? If you really feel that strongly about it? Go ahead and use cute names. For your service. The rest of us will be using boring names, and yours will be the odd service out, because you don't get to tell the entire team/business what to do by fiat (unless you're a horrible micromanager).
Read their first two paragraphs again. They're talking about individual services (and so am I). Steeringwheel-svc, Rackandpinion-svc, Shifter-svc, Engine-svc, Transmission-svc, Axle-svc, Tire-svc. Same as filetransfer-frontend-svc, filetransfer-batchloader-svc, filetransfer-batchtransform-svc, filetransfer-db, etc. (those names might still be too generic, but at least you know what I've just described)
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.
Why not take this to its logical conclusion and name modules, functions and variables cute names too. You need to understand the program and the code could be lying to you with its naming so why bother to name them at all. Start with Pokémon characters, atomic elements, geographical features etc. The possibilities are endless! This naming strategy can also save time when refactoring because you can change the meaning of a variable (for example) without having to rename it everywhere!
I work as a developer at a consulting company, and the consultants are constantly writing new scripts, Excel templates, and so on. Most are early career and get excited about having created something new, so they like using cute names. The practice has been to use a bird name.
So my life consists of bewildering sentences about how raven is old and busted but blue throat will handle this situation, especially if used in concert with agelaius and peregrine, and run on a greyhawk.
TFA is utterly wrong. A few things can perhaps stand the test of time and be worthy of a name, but use cute names sparingly. And, resist the urge to name something at all—it is far better to use umbrella terms inside an organization to avoid mass confusion by those that don’t need to have day-to-day knowledge of your software.
We use bear names. It is fun and at this point (for me) the names are second nature.
But the company merged recently with a couple of other companies and the confusion about polar bears versus grizzly bears versus panda bears is pretty funny at times (and counter-productive).
I try to use both the code name and the descriptive name. So now I say something like: "grizzly marshmallow roaster" instead of just "grizzly".
> The world is boring enough as is. Let's add more whimsy and cuteness through our service and project names.
This is a recipe for creating a wholly impenetrable language about your services. Which is easier for an outsider to understand:
"I updated the code for how Batman writes to Goliath in Cair Paravel"
"I updated the code for how the backend services write to the customer database in the billing application."
> 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.
What seems to happen more often at the particular Large Company I work for is that not just responsibilities change, but fundamental assumptions underlying the architecture of a system change every few years. So rather than renaming a service, often a new system is put in place that reflects these new assumptions, and this new system will have a new name. The migration then isn't about the new name, it's about the new system, along with the new APIs and model of operation that comes with it. Yes, there are lots of examples of billing systems written 40 years ago in COBOL, but most software systems have a lifecycle on the order of 3-5 years.
I don't buy the "can't rename services" arguments though. It's also hard to rename variables, modules and stuff. We do it. I'll tell the PM I need to rename this function if they want to know what I'm up to. How often does a service morph so much that it needs to fundamentally change its vaguely-descriptive-name? Realistically I don't think I've even seen this happen once.
I think the "can't rename it" applies to APIs. Some of the PDF functions have COS as part of their name. The original name of Acrobat was Carousel. COS stands for Carousel Object System. The first version of Acrobat was released in 1993.
> I'll tell the PM I need to rename this function if they want to know what I'm up to.
Why can't more engineers do this? in my experience people rarely ever question the product team and you can see this in the products you use all the time. PMs are not robots, they do things the way that seems best given the knowledge they have of the customer and the software, but engineers have more knowledge of the software and they need to communicate it when it's relevant instead of overcomplicating features by blindly shimmying in what product is asking for.
You can call it by the cute name in casual speech and still guess what it does by looking at the process/deployment/artifacts name. "I'll deploy knock-knock-whos-this this afternoon" -> `kubectl apply -f knock-knock-whos-this-authn.yml`
> 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.
I couldn't disagree more. This is exactly why you would want the name to be descriptive. If the thing that's supposed to be a notifications service suddenly also starts processing payroll, that's absolutely a friction point that should give people pause.
Could not agree more. Naming things for what they do encourages other behaviors like deprecation strategies and extension strategies that are non-disruptive to others. It makes people's lives easier if your work follows a level of rigor for naming. Products and companies can do many things under a single name, APIs should try to do the fewest number of things under a given name while fitting the concept as closely as possible.
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.
Well, I have worked in an environment where database server names were server software version concatenated with a shortish but high entropy random alphanumeric string. I'll take cute or descriptive any day over that.
I've heard the "cattle not pets" argument for servers, but I hate that. Naming a server is like naming a boat. I've done it where everything is named after astronomers, or physicists, or even comic strip characters, but I also like it when a server is named, well, with a name.
"Hey guys, Jeff is throwing errors again, need somebody to find out what Jeff's problem is."
It depends on scale. If you have 3 servers that you manage individually, you name them like pets. If you have 3,000 servers that you manage through automation, you enumerate them like cattle.
Sure, I get that. Not many do that, but they still name their handful of servers "EDG-12-XY-NY-001-WTF". When it would be so much better if it were named "Doug".
As a sysadmin who deals with several clients with different naming conventions wrt server hostnames, i feel like both schools annoy me;
for example one of our clients has FRPRTFSQL02, where fr is france, pr is production, tf is the app this server relates to, sql is the type of service this hosts, and 02 is sequential, so for an sql server this means it's most likely a ro replica.
On the other hand, another client names their servers just "montana", "barcelone" or "morroco" with no relation to the geographic aspect of the name.
In both cases, and maybe this is just because i work and exist in this wierd liminal space where i care about the server but not what's on it (if i end up caring what's on it, i find out what i care about by looking at logs etc, not the name) so both ends of the spectrum tell me absolutely nothing about the machine and it's just an annoyance to remember them. I find cute names easier to remember and tell my coworkers about, for what that's worth.
On my own infra, i name my servers with simple descriptive names, like "matrix" is hosting matrix and "play" is hosting game servers, but i don't have the infrastructure for that to be a problem (ie i do not have 2 copies of anything running) so i can afford to do it, but i know it's not a good solution.
His point is good though. Descriptive names add overhead that might need to be changed.
Giving something a cute name but describes its general purpose, means you have a lot of leeway, but if you get to the point where even the general name doesn’t work and you want to change it, then you actually have a new product and creation is better than evolution when it comes to software.
Joey, the small service that hops from one place to the next in what seems like ~~ab~~an endless loop, is like a baby kangaroo, and it can even grow into a real kangaroo and do whatever they do, but it isn’t gonna become a fire breathing dragon, and if Joey is trying to be forced into being a dragon instead of a kangaroo, well maybe it’s time to start from the beginning and decide which programming language to use ~~snd~~and go from there.
Think of it, instead of writing software, we just write fantasy stories, and the software that tells the story is our product.
I don’t know about you but I could probably come up with some cool stories of Joey the baby kangaroo.
I’m going to start a company and name all the services and APIs supporting the software after the best characters from mythology, and just start making good characters and then figure out where they go in the story.
The story is already written, but the characters have to be fleshed out.
Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course.
Vitriol's correct name is "sulfuric acid".
Salt's correct name is "sodium chloride"
Cholesterol's correct name is "(1R,3aS,3bS,7S,9aR,9bS,11aR)-9a,11a-Dimethyl-1-[(2R)-6-methylheptan-2-yl]-2,3,3a,3b,4,6,7,8,9,9a,9b,10,11,11a-tetradecahydro-1H-cyclopenta[a]phenanthren-7-ol".
That's not a name! It's a serialization of a molecular structure!
See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding. It's like the argument between natural and artificial primary keys. If you go with natural primary keys, expect managers to bikeshed exactly what's in there and how it should be encoded. They'll change all the time. Your "name" turns into an encoding of the object itself. If you call your computer "OaklandDev19InTheBasement" then what happens if you move? What happens if you get more than 100 dev computers in the Oakland basement? How many arguments are you going to have about whether it's the proper place to put some service that may not be "devvy" enough?
Some people are hitting this, but most of these can be broken into different functions:
Identity: always meaningless, always.
Finding a service: if this is hard, you need a directory. You need this anyway, even with descriptive names. If you need a directory, can you automate it?
Of the three you mention, only "cholesterol" was actually named by an early chemist [0]. "Oil of vitriol" was first mentioned by an alchemist almost 1000 years ago but the term "vitriol" already existed to refer to some metal sulfates. "Salt" is much much older.
I was really hoping we'd all be mature enough to not have this petty argument over when people studying the properties of chemicals stopped being called "alchemists" and started being called "chemists". What year was that, exactly? Exactly. I need an exact year, so I don't make this "mistake" again, please. Because otherwise, I think "early chemists" is a perfectly accurate description of early humans studying the properties of chemicals.
The transition was gradual but did happen, and on one side you had a lot of pseudo-religious beliefs and on the other you had experimentation and the scientific method.
And this distinction is important enough to you that you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists", and if they don't, you're going to correct them? Even if it's irrelevant to their main point? That's the discourse we want on here?
Everyone had pseudo-religious beliefs back then! Can we not talk about "early astronomers" who were studying the movements of stars and planets, if they also believed in other weird shit? Who cares if they were studying the stars in order to sacrifice goats at better times?
> you'd like everyone who refers to pre-20th century humans who studied the properties of chemicals as "early chemists/alchemists",
"Alchemist" has a specific meaning, and it is not synonymous with "early chemist". Robert Boyle was
clearly an early chemist and predates Isaac Newton, who was an alchemist. There is no temporal hard line in the sand, the distinction is made based on methodology and goals. The two terms aren't necessarily mutual exclusive (as with the astronomy / astrology distinction you allude to), but that doesn't mean you can conflate them.
> Everyone had pseudo-religious beliefs back then!
Perhaps, but that doesn't mean there aren't relevant distinctions to be made about their beliefs and methodologies.
While this distinction is important, it is also irrelevant to my main point. "Vitriol" predates that alchemist and is arguably more of a word that arose than a name that was given.
Even if it’s imperfect, a descriptive name is quite nice because at least it gives you a hint as to what the service does.
I find the comparison to cholesterol to be a bit ridiculous. Your argument seems like a case of “well technically this strategy is imperfect so we shouldn’t even try.”
There are so many straw man arguments in this post it's hard to play them apart.
> Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course.
That's not what happened, and nobody is saying that the chemical serialization is the "correct" name. The reality is that originally we didn't know the internal structure of these chemicals or understand how they functioned: referring to something as an acid didn't matter because we didn't understand how acids worked. The naming grew as our understanding of the function grew.
But, critically, the old names are still useful in some contexts, because the chemicals serve different functions in different contexts. Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol. In fact, it's telling that your chemical structure actually is just one form of cholesterol, because cholesterol is a group of chemicals, not one chemical.
More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services.
> See, the problem is that what's "descriptive" is opinionated, and a hot topic for bikeshedding.
Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson.
Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time. That's true to some extent, but having to figure out what a poorly-named entity does is a much larger waste of time. And if it isn't, I have to ask, why is changing names taking so long? Perhaps it's a lack of tests? Poor editor tooling? Whatever it is, fix whatever is making your names hard to change, don't give up on descriptive names.
> The naming grew as our understanding of the function grew.
Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and useless as Cholesterol's "true" name.
> Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol.
Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service. So the name "TextCheckerTranslator" is partially irrelevant to both. And what happens when you add a third function to it? It now can also do OCR. So now your CRM program, which only cares about the "checker" part, needs to be re-compiled or have its config changed because it now needs to call the "TextCheckerTranslatorOCR" service instead. Every downstream service has to be changed because of changes that have nothing to do with them! Just call it "Wordsmith".
> More fundamentally, naming the structures of chemicals is different from naming services, because chemicals don't change. Sulfuric acid will always be H2SO4, and it will always react the same given the same conditions. That's not true of services.
Our understanding of chemicals changes, just like our understanding of which services should do what (and what that means) changes. But either way, if services are more likely to change, then all the more reason to use artificial names for them (rather than trying to encode all their purposes).
> Sure... but the answer is just "don't do that". If you spend 30 hours a week arguing over whether something is a "adapter" or a "converter" that's a waste of time, because those terms are both pretty similar. No one is saying that's a good idea. That doesn't mean that we should just throw up our hands and name the object "SamuelLJackson", it means we should give things the most descriptive name we can come up with in, say, 30 seconds. Which, for something that changes objects from one format to another, isn't SamuelLJackson.
Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words. I agree the word should not be completely divorced from its use. SamuelLJackson would be a good name for a service which takes boring text and liberally inserts creative swear words into it.
> Part of the problem I'm seeing here is that people seem to be concerned that name changes are a waste of time.
We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes. The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.
> > The naming grew as our understanding of the function grew.
> That's exactly it! You have accidentally made my point exactly.
No, you just ignored the point I made later about it being contextual.
> > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol.
> Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service.
1. ...but your CRM service does need to know that your spell-checking service is a spell-checking service, and your international logistic program does need to know that your translation service is a translation service.
2. Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service. If you violate single responsibility principle, then "Play stupid games, win stupid prizes" applies. Naming is the least of your problems in this situation.
> Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words.
Well, maybe until you're better at it, spend more time.
> I agree the word should not be completely divorced from its use.
Then you disagree with the OP.
> We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes.
Again, play stupid games, win stupid prizes. If every part of your code depends on every other part of your code, don't do that.
> The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.
Surely what the thing you're calling does is relevant to you?
I think we have very different situations in our mind as we go bath and forth like this. It'd be fun to discuss this further over beer, but I think we've mostly hit the limit of what we can do in a HN thread. I'm picking the one major thing you said that I disagree with most:
> Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service.
I just want to stress how tremendously inflexible that is, and just how heavy of a decision you have to make any time you implement a new feature. This sounds like all the negatives of microservices (or DLL hell if that's your deployment model) with none of the positives. Boundaries are fuzzy! I have written a spell checker before. Later I needed an auto-complete service. Turns out: serendipity! I could implement auto-complete easily by simply implementing a separate error model that didn't take off points for "deletion errors" at the end of the word. And as a bonus, it was "fuzzy", so if you typed "Arnold Shwarz" it would suggest Schwarzenegger even though you missed the 'c'. The difference between the Spell Checking Service and the Fuzzy Autocomplete Service was one class of about 10 lines.
If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins. And maybe you decide autocomplete is close enough to spell-checking to warrant being in the same service, but your colleague might not, so now you needlessly argue over it. It shouldn't be a big decision! Just write it! So auto-complete goes in the service, but it's really close to feature X, which involves vectorizing words, which is the basis for a translation service. Now your spell checker is also a translation service. But what have we really lost? Who gives a crap that Wordsmith now has an extra feature? Nobody who was using its old features; they don't have to change at all.
> > I spent about 30 seconds coming up with "Wordsmith". It does something with words.
> Well, maybe until you're better at it, spend more time.
Needlessly nasty. Maybe I don't want to have a beer with you after all. Come on Wordsmith, I think you're beautiful just the way you are.
> If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins.
It's not "immediately setting out with a mindset", it's looking back on coming-up-on-2-decades of software development experience and noting that every time I think bolting a second responsibility onto a unit is an easy win, that decision comes back to bite me. It seems like an easy win now, but everything you change in that area of the code from now on needs to consider two different, disparate responsibilities it needs to maintain.
If you're seeing this as an easy win, it's likely that your software didn't see much use that played out the problems, or you didn't stick around long enough to see the problems arise, or someone else did the work to fix it and just didn't tell you.
> Nobody who was using its old features; they don't have to change at all.
Not yet, but if you assume they'll never have to change, you're going to have a bad time.
What's the longest you've ever worked on a codebase? Have you ever been the sole developer on a large codebase, where you had to pay for your own mistakes?
> Needlessly nasty. Maybe I don't want to have a beer with you after all
I don't think it was nasty at all. If you'd spent more than 30s on it you'd know that "wordsmith" already means "a skilled writer" and thus doesn't match the function of the tool you are describing. Names that appear to describe the function of a thing but don't are IMHO, the one of the worst kinds of bad names. You're better off with something that is either completely divorced from the underlying functionality or describes it correctly.
When U.S. law applies, trademark lawyers urge companies to find "suggestive" names — requiring insight to realize "ah, that's what this is!" — as the "sweet spot" to get the most bang for the buck in marketing while still being legally-protectable. (Examples: Coppertone for suntan lotion; Greyhound for bus-transportation services; Energizer for batteries.)
"Merely descriptive" marks can't be protected legally without proof that they've acquired "secondary meaning," e.g., through widespread advertising, going viral, etc.
"Coined" or "fanciful" marks such as Reebok and Kodak, and "arbitrary" marks such as Lotus for software, are protectable, but they don't do much good in advertising, at least not initially, because customers don't know what product or service is.
From experience, this is thew worst possible decision to make in anything apart from the smallest of organisations (i.e. where production is small enough that all the engineers know (like, really know inside-out and have it all in their head - not just "aware of")), at which point you don't have much to worry about when it comes to renaming something.
Please, put yourself in the shoes of someone else. Someone who doesn't know what "PonySparkles" or "B-52" or "Starling" or "Hydrogen" or "Pokemon" or "PapaSmurf" or "ProjectSmart" or "Dylan" or "Everest" or "Kathmandu" are, or doesn't get the "joke" about why this thing is called "TinkerBell" and not "BroadcastService".
The original owners/authors will inevitably leave the company, and new-starters won't know what the names are unless someone tells them (and even then I can promise you they'll be thinking "why did you call it that?"). Discoverability will also be poor, so someone else in the company will probably end up duplicating your effort because no one realised that we already had BroadcastService, or struggle to understand why they cannot get <some simple thing working> because it is impossible to understand what needs to happen without knowing the Secret Gatekeeping Knowledge of the magic Cute Names they need to know about.
Just look at AWS service names as an example - what the hell does BottleRocket or Textract or Polly or Route 53 mean? You have to go read docs to find out what those Amazon services actually do.
Just please don't do it. Please use simple general words that are descriptive and as obvious as possible.
As per the article: The problem is that descriptive names don't stay that way. Descriptive names turn into misleading names as the things they refer to change over time. And while code can be refactored, it's very hard to refactor a service name, and almost impossible to refactor it away from people's minds.
Cute names are basically the equivalent of calling everything in your code "variable_1", "project_2". Descriptive names may be misleading, but at least they attempt to capture the intention rather than completely disregard it.
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
This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding of them. It's a pivotal issue, in how it attaches our brain-maps to the problems we tackle.
How many times, as a developer, have you paused and pondered what to name a new entity? I often find the difficulty of naming a thing is directly proportional to my depth of comprehension of that thing, what it does, and the context it lives in.
With that in mind, I see naming-things-for-what-they-are as one winning strategy.
Quoting from OP:
> The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.
I find this a bit misleading, since Sam is a person with agency and a unique personality, and the things we name are, well, things, with specific purposes and raisons-d'etre.
But! At the same time, OP identifies a key characteristic of things-that-persist -- scope creeps, features are added, responsibilities evolve. Naming a server "Sysyphus" may seem cheeky at first, but I'd argue that it's a better name than "Load Processing Server 2". We tend to antropomorphize things, that's one, but also - things happen over time, notable events, that create a timeline of stories which in turn build up into the coherent base of knowledge / familiarity / wisdom that ties teams together. Using "humanized" or "personalized" names pays off here, they help to glue these stories together and contribute to the institutional memory that builds up over time.
In the end, I think both approaches are valid and have their place, we just have to use our judgement as to when to use which.
> This is one of the hardest problems in software development
and that is one of the worst fallacies in software development
naming things is not hard, people regularly give things terrible abstract names because they act like it'll never be possible to rename it and then add a 3-4 word comment above describing what it does
if they just named it what the comment says then they'd have a fine name
I've worked at a place where we had dozens of microservices, all named after random mythology. And all names must had some relevance to the actual function of the service.
The shopping cart service was named Freyja[0].
The content management service was called Metis[1].
Every single service had a 'cute but descriptive' name, and it was hell.
If you didn't know that tale, the names don't mean anything. And if you do know you still have to guess what the the service does.
It seems the author correctly points out some problems with descriptive names, but then advocates for "fun" names without explaining how they deal with the problems. So the solution is that they are "more fun" and give up on solving the problems whatsoever?
I've dealt with cute names in past jobs. Because they are meaningless ("Thoth"? I think that's an Egyptian god, but what does it do?) I've spent months confused. And when I didn't deal with them, I forgot what they did, especially since in the microservices world there's so many of them.
I'd rather have a slightly outdated but descriptive name than a completely meaningless "cute" name.
> It's impossible to predict with certainty how your software's requirements will evolve over time. And if you don't know what your software will need to do later, you don't know what the ideal factoring will be then, let alone now. It will almost certainly change over time.
If you follow the idea of the "Single Responsibility Principal" with discipline, then you should create a new piece of software if changes to it would drift too much from what it was named. If you have a lawn mower and you start trying to use it as a mulcher as well, you will be a lot better off creating a new product called a "mulcher" intended for just that purpose.
..Or create a new product with a standard connector for both, an adaptor for lawn mower and another one for mulcher, using the same engine. It can be called Mulchwer - cute and descriptive! When the company inevitably invents a new adaptor, say a snow blower for clearing the sidewalk, the product can be renamed Mulchwer X, or Multi-Mulchwer Deluxe. It's now an all-purpose product with a set of adaptors for any front/backyard needs. It will also be a subscription-based business model, always needs to be connected to the Internet, and have machine learning for full self-driving.
There is plenty of successful companies with descriptive names. Facebook, IBM, BMW (Bayerische Motoren Werke), Grammarly, Duolingo, OpenAI, etc, etc.
Personally, I prefer this approach. When a company gets big, it does not matter. If something is small, at least I get a f---ing clue what it does (and it is easier to memorize).
I too like cute names at high levels of abstraction, because descriptions or explanations shouldn’t clash with the named bits—particularly in documentation.
But when a named thing doesn’t escape the code files, then it has to be descriptive. My projects take too long, and coming back to a too cute name is a PITA.
The exception is I use
verb+cute name for command line script names.
Curiously, this week I was doing some project in Python where a visual plot was necessary. Now here’s a sphere where naming actually sux. I say this because there is a rich history of terms around visuals. When your project includes these other ontologies, it’s not so fun.
My thoughts exactly. Cute names are identities: you apply them to things that are unique and where the purpose is malleable. Functional names are descriptions: they capture the thing's purpose, not its identity.
Imagine starting at a new company and you view a big diagram of all the services. "Flipper connects to klunker, which has a database called plomb. There's an arrow going from gonky all the way down to zippydoo, which generates a report that gets handled by fogle. And all this is orchestrated by butt".
I also like descriptive names because they help me fend off service bloat. "Sorry, it doesn't make sense to add bespoke client integration to report-generator. But we can make a new service which takes those reports and sends them to ABC Corp if you want."
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.
* It does not change either in time or space -- you have to come up with a good name right from the start and then you are not allowed to change it. The same thing has to be named the same way throughout the system and ideally through multiple connected systems.
* It must not mislead -- the name does not have to be super descriptive (although it is a desired property) but it cannot cause you to think the thing does something it doesn't do.
* It must be unique -- the same name cannot be used for different similar or dissimilar things.
I agree. The uniqueness and stability of a name is key. Then making is not mislead is good. Then being descriptive is nice.
I think the article is hitting on descriptive names can become misleading over time. People will think that a descriptive name is helpful, even if it was poorly chosen or is no longer accurate.
I think the author has a point here. In an ideal world, we would of course spin up a new microservice every time a PR in the foobar-widget-generator service begins to deviate from generating foobar widgets. In practice, we make delivery tradeoffs all the time. It's not at all uncommon for service scope to creep while a new, urgent feature is being experimented with. And launching a new service is never, ever going to be as cheap as updating an existing, well-maintained one.
My own hard-line requirement when it comes to naming services is that they should be a single word with some relationship to the service's purpose. Ideally a common English word, but proper nouns are permitted if they improve clarity. Brevity must ALWAYS take precedence over clarity. There's only so much you can express in a name anyway; a detailed explanation of exactly what a service does should exist in documentation.
Otherwise you end up with long names like "horizon-blob-profile-server" or "batch-process-execution-engine". Multiple words lead to ambiguity. Inevitably you end up using dashes, camel case, underscores, or no differentiation at all in order to represent word boundaries in different systems, because VCS, filesytems, domain names, and cloud systems all have different sets of permitted characters. This makes automating your infrastructure painful.
And of course people resort to acronyms when discussing the services, which means everyone is forever getting the dfkg service confused with dkfg. "Whoops, I deleted the wrong database!"
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.
Another issue I have with descriptive names is that wrappers and other components quickly get out of hand, then you have machine-learning-worker-wrapper-utils and conversations about this become impossible.
Someone argued that cutesy name hides the responsibility; Personally, I think the effort of resisting making cutesy name do stuff it wasn't originally designed to do is well worth the ease with which you discuss these now concisely named components.
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?
This reminds me (from a long time ago) of seeing IT department stick names of jungle animals on computers so they can be recognized on the network.
These days, there are many cases where _instances_ of something are given random "cute" names. A particular server will have a suitable-for-work but fun name slapped on, like "grumpy goat".
Hover, I can't imagine _classes_ of something following that kind of naming convention. This post seems to be more about _queue_ names or _service_ names. Software DOES intentionally use cute and random names for big-ticket items (see "git"). It would be confusing to apply this practice to more minor software, because it would be too many to remember.
If I have a service as a part of an app that consumes data from a redis queue and sends it to a log collector, a fully descriptive name is distasteful, but I wouldn't want to name it "anteater" because even if my mental picture is vivid, other people will... not get it. I'd call it "log-passer" or something.
I'll put in a vote in favor of cute names, in the specific scenario of talking (out loud) about specific services - it's less clunky and personally, way easier to correctly parse cute names than common-words-which-may-combine-into-a-service-name.
To take some examples from public cloud:
"We can put that data in Cloud Storage Archive" vs. "We can put that data in Glacier"
"This service runs as a function in Azure Functions" vs. "This service runs as a Lambda function"
"Use the standard machine image" vs. "Use the standard AMI"
On the other hand, I did work on a system where all the services were spaceship names, and that was a nightmare to onboard people onto... echoes of https://www.youtube.com/watch?v=y8OnoxKotPQ , especially as one was named Galactica
> The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.
This analogy falls short. Services aren't like people -- their names aren't bound to their origination, but they can be bound to their function. That's a choice for a developer to make.
But how common are are actual mismatches between service responsibilities and names, really?
What kinds of systems or features or teams do name/function mismatches commonly track?
Speaking strictly for myself: I've worked on SOAs and microservices (mostly for .NET) since 2005 for half a dozen companies on both new and existing systems, and I can't recall _any_ such mismatches.
Last company I'm worked for named all their services after Toy Story characters and no one knew what anything did. "So Woody talks to Buzz that lives on the client's server and then pushes the data to Pizza Planet where Sarge queues it up to Bopeep". I hated it
Don't do this. I see these names as just obvious ways to describe what things do like variables. I wouldn't want to be reading code like
```
beeblebrox = zaphod + trillian
```
similarly names of services in architecture diagram shouldn't be undecipherable (outside of perhaps ultra secret projects -- then maybe those agencies should have a name generator :) ). The cute names even if based on some theme get very old and the cultural context almost always gets lost once the company/team outgrows. Also it's a much easier to refactor away a new service if lets say you find yourself adding a completely unrelated feature to a service named "accounting" or something boring,whereas if you named it "hades" or something cutesy, you don't have any indicator whether the feature has outgrown. I've found it much easier to deprecate/sunset services and systems when they're obviously named too.
One exception I'd say is when nicknames just arise and it becomes obvious to call it that. It's very rare and it happens. Borg at google is perhaps a good example here. It's so all encompassing that it's obvious what it means and calling it another name like "container orchestrator" or something similar perhaps doesn't have same gravitas. I think Microsoft had something called Autopilot which is even clearer but not it can be applied to many things.
Leave cutesy and or funny names for instances of software, not the software itself. You can have a complicated java program with dozens of classes and high levels of abstraction all named with the usual 'boring' names, and run an instance of that class an have it called r2d2, ultron, or "An Eridean named Rocky". That antropomorphizes the program, which leads to higher acceptance and easier internal communications.
I am so sick of everything having a cute name. Projects can have a cute name; components should not. Imagine if cars did this.
You'd get into your car, and it can have a cute name because it's one name to remember and your car can just be a "Jetta", but the "steering wheel" should be called that. Otherwise you can't go anywhere because you're not sure if you should chauffage the afiafi before you cosmo the thanos.
chauffage: french for "warm"
afi afi: samoan for "motor"
cosmo: from the Jetson's Cosmo Spacely, maker of sprockets
thanos: no logic whatsoever, I just like the movie (and a bit of whimsy is cute, right?) --good luck trying to figure out what it refers to, I'll probably be gone from the company by the time anyone notices
People complain that naming things is hard, but I argue that it's hard if you don't have a good understanding of what the thing is.
Hard disagree. Especially for backend/infra or any cross team usage. One of my previous company widely popular for crunching logs had starwars esque names for various services and Kubernetes infra. It was a terrible decision, since it lead to another layer of abstraction to know what those meant in the context, also when employees churn, reorgs happen, a lot of this info gets lost into oblivion.
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.
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.
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 worked at a place that did the typical geek naming thing, with the Greek and Roman pantheon. They were cleverly chosen, so that you could remember that "mercury" was the messenger, and so on. But still, you couldn't tell anything from a name unless you already knew the connection.
So we went with serious names: Message Sending Service, User Account Service, and so on. And the result is that every service has a valueless "Service" appended to it and everyone just throws acronyms around now. So you can't tell anything from a name unless you already know the acronym.
Overall I think the answer is that things that involve a lot of interaction can have creative names, and things that are rarely interacted with have to have more meaningful names. Call the monolith "Princess Unicorn". Everyone will end up knowing what Princess Unicorn is through proximity. But call the annual billing reconciliation process "Annual Billing Reconciliation".
Nobody today would believe naming classes after greek gods or anime is a good idea, but for some reason it's okay for (micro)services.
I've worked at places that do this, I think it's a bad idea.
Not having descriptive names turns architecture discussions into bikeshedding ("I think we should create a new service named Pikachu instead of extending the scope of the Naturo service").
I read this article and was surprised it was written yesterday because I could have sworn I read it a few months ago. Turns out I was remembering a post by a different author making the same arguments, discussed on HN here: https://news.ycombinator.com/item?id=32807969
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
False dichotomy; descriptive names can and should be cute, if you're willing to spice them with a bit of analogy and/or irony. Problem is that most corporate programmers lack personality (and punk spirit, tbh), and use names as a way to make their code appear "compliant," (boring)
deflecting attention and scrutiny from their work.
It get’a interesting when different companies decide to go down the Greek mythology pathway and the same service names pop up with different meanings in each company :)
Also worth mentioning this as always humorous micrososervice video from Krazam many of you may know already:
I've flipped between these two positions (descriptive and... not descriptive) names.
I settled on nondescript and just mash two random words together when making a new project.
~90% of my actual work projects are less than 10 files of source code anyway (not counting dependencies, readme, make file, requirements.txt, etc). The vast majority are one file Python or Bash scripts.
Horrible advise in this post, names should be DESCRIPTIVE/MEANINGFUL because a critical rule of marketing says that provide solutions to people who are already looking for it. Therefore if you want your service/product to show up on SEO/Search, use descriptive name and not a cute name that no one knows what it means.
Lots of people pointing out how bad this is for new hires, but it’s not just a hurdle for new hires to get over… in a lot of cases people will just _never get over the hurdle_. The discussions outside their team will just be a bunch of gobbledygook that they tune out. And years down the line you end up with a really Balkanized engineering culture. Where you know what happens in Zeus, but you have basically blocked out Persephone, Ulysses, and Palmyra because they are another team’s responsibility.
Maybe that’s actually a good thing for some organizations, I know many CTOs spend most of their time trying to make cleaner separations between teams.
But if you want a culture where people understand and evolve the larger architecture from time to time, cute names are going to make that less likely.
The right question to ask is how and when hostnames are serialized to disk and how you need to interact with them. The most common in my experience are for logging, metrics, backups and monitoring. So those interactions are important use cases to consider.
In my opinion a good hostname, given an enterprise setting and in order of importance, should reflect 1) if the host is production, a staging area, or someone's toy, and 2) which group or team has responsibility or it. If relevant, also 3) what type of server or role it is.
Should you find some sort of data dump or log that contains a hostname, it should be immediately obvious how sensitive it can be and with whom to speak. This basic requirement mostly rules out "cute-only" names.
Sorry, no. Service naming is essentially the same argument as module or class naming. We've already had that argument and descriptive names are king for reasons that have been explained to death over the past decades. Could you imaging going through an unknown codebase and finding that all of the names are "Scooby" and "Rumplestiltskin" instead of "RenderPipeline" and "UserInput"?
If your service starts taking on responsibilities that render the name non-descriptive, then it's likely taking on responsibilities that it shouldn't, and you need to have a talk with your architect, same as you would with an entirely local app.
Brands are hard to change. Is your thing a brand for your company? Probably.
You need your "cute" name (branding, differentiation, trademark) and a descriptive name. "Marmaray" tells the reader nothing. "Marmaray Tunnel Service" is more informative. Of course, once your fellow conversants become accustomed to the vocabulary, "Marmaray" is going to save time during speaking. Until then, you're just going to have to be aware that you'll need to educate folks along the way.
I find it outright pretentious when I hear anyone using strings of "cute" names with no attempt at actually explaining the stack.
I kinda wanted to agree with the author because of the number of times I've encountered and X-Yer that's neither X nor Y anymore.
But honestly even in those cases it's still usually somewhat informative despite the argument that it's misleading. It's still got some essence to it, and having a clue about the history is also often useful.
And it's frequently abbreviated XanYat or some such, or initialized the XY, which is just treated as any old name anyway and not a description. It's not cute or fun, and maybe less memorable (not sure about that, a single cute name is memorable but an ocean of them sounds confusing).
> A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. Your service which started with a nice, tidy set of responsibilities may start to shift over time. And then you're faced with a choice: keep the old descriptive-but-now-wrong name, or put in all the effort to change it.
I had this happen recently. We wrote an application with two major components: one that processes events and repackages them as generic events and a component that receives those events and schedules work. We work in a compliance heavy environment so the architecture often reflects a separation of concerns given the information being processed.
The scheduler became pretty popular for people to plug into, even if they didn't use our other component. The scheduler eventually left the nest of our small, purpose-built program and became general infrastructure. It's now the "SecureScheduler", though on our component diagrams it simply goes by "scheduler".
My lesson learned was that if you properly separate an application out, the component names can become independent software in the service registry over time if they need to. The scheduler is pretty strictly scoped, so it'll never start doing new zaney things. It simply schedules work in a controlled environment.
These arguments over cute and functional names, I think, are a byproduct of a couple failures:
- Properly naming and confining components role within a single service. Our scheduler was generic enough to operate on its own, but it's role within our architecture was pretty confined. It's main optimization compared to other software like it was the inbound communication and authentication flows that made it easy to securely plug into.
- Lack of organization and vision at the service registry level. The scheduler didn't need a vastly different name, because it's purpose didn't really change. It did one thing and it did that one thing exceedingly well. There was a hole in the wider service registry that it could fill. As a result it was elevated to its own program in the service registry with its own deployment schedule.
TBH, I don't care if your names are cute or descriptive, but for the love of God, can they please be Google-unique? I don't want to search for a particular software tool and end up getting loads of results about hamsters.
> The world is boring enough as is. Let's add more whimsy and cuteness through our service and project names.
Cute names suck, a list of them obfuscates a development stack to newcomers and they’re just hard to take seriously. At my company, we have Jira, SumoDB, and Java. I wonder what that means to a Business Analyst, surely they know straight away.
The hipsterdom in the tech world is cringe. Go teach (force) your kids to learn Python with the children’s book you wrote. Oh and don’t forget to give it a cute name that sounds Japanese or like a type of tea, we need more of those…We’re totally not going to look back on cute names in 20 years as a silly fad
What annoys me is when internal code names are used all over the place throughout the code base. Sure it might make it easier for those steeped in years of company culture to navigate the code, and provide a slightly more playful company culture, but it makes it an absolute nightmare for a beginner to find things.
Furthermore, I often see companies use trademarked words for internal code names, which could lead to problems if their usage is leaked outside the company. I can’t remember what it was but I recall reading that such use of trademarks for internal code names led to legal issues for a company.
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.
I think "either this or that" type of thinking is unfit for the topic. A better strategy is to setup a priority: making the name descriptive should be very close to the top, and making it also cute should be somewhere down the line.
Also, cute is really subjective. Personally I think "Continuous Integration/Continuous Delivery" is cute and "cli-anal-stats" is very cute, even through you might not think of it the same. The advantage of descriptive names is that it's more recognizable, you read the name, you knew what they do, and that's cute for me.
I name all my machines after a theme, unlike a major organisation I don't have the money to have dns-server-0 and dns-server-1 which ONLY host an authoritative pair of DNS servers and then web-server-0 which ONLY hosts my website etc etc.
But if you can guarantee that something will continue to be one thing for ever and ever, I think maybe a descriptive name can work. It really depends on what level of analysis you're working on. Services probably shouldn't change their core purpose over-time, but business pressures may result in them changing their core purpose.
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.
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.
For broad services and product lines, this is 100% correct.
Change is inevitable and having a simple (cute) name allows collective semantics to float with reality as it changes.
Of course for less volatile components, descriptive is useful, almost necessary.
One of the most important skill sets in putting together technical systems is understanding the difference between volatile vs stable components.
The problem I’ve found is that so many technical people can’t fathom change or see where change is inevitable. So they operate as if everything is stable.
That’s why you see so much pushback against the idea proposed here.
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.
I'm strongly in the camp of cute names. They are memorable identifiers, nothing more.
Cutesy names are greppable, meaningful names are not. 'billingmurray' Vs 'account service'
Giving meaning to a service through its name is also mostly nonsense, since no name will convey enough information about it's responsibilities for it to be meaningful anyway.
Besides, all of the systems and services you use are either acronyms or cutesy names already. Docker, Linux, Unix, qwerty etc. They're just labels.
We have Spotify, not music.com, and Amazon, not books.com.
In organization chart data, there are people with cute names (John, Jane) and there are positions with descriptive names (Head of Product, Head of Sales).
People's responsibilities change but their cute name does not. But you might not know everyone's cute name, and you want to know who to talk to when something was sold that can't be fulfilled. So you look up Head of Sales in the org chart.
Perhaps having two names is what is needed as in organization charts.
I’m at a mid size company that is currently moving away from cute names onto meaningful names.
I’m glad we’re going in this direction as the onboarding process was painful, trying to piece together so many arbitrary facts, and I’m reminded of this pain every time someone joins and I have to talk them through architecture diagrams.
Using meaningful names will force us to maintain microservices that honour the single responsibility principle.
Scope creep is a form of tech debt, which must be repaid as opposed to being tacitly endorsed by naming services with mutability in mind.
I work somewhere where naming is notoriously bad both cute and descriptive. If I could wave a magic wand about naming, I would wish that people put less time into thinking about naming. You get better names that way.
A simple exercise in improv could even be applied. What's the first thing that comes to the top of your mind when you think of "X"? If majority of people say the same thing, you run with it because that's the most obvious one. Choose the obvious one.
(Micro)service names should be descriptive and stick to doing what they are named after. If you need to change the scope, it's an change to the overall architecture and changing the name and good way to communicate that. If a employee reads the name they know what its suppose to do.
Company and product names (including e.g open source projects) are different. You want to be able to change your scope depending on customer demand without having to rebrand.
I think this is probably two far to one side. It is true that naming something purely descriptively may lead to misconceptions as its function evolves, but a "cute" name doesn't do anything to inform someone what it is. I would argue that best name has some semantic connection to the function, but is also somewhat abstracted; This allows it to be informative while accommodating evolution.
The word “transaction” is so overloaded it would be pointless to use in a system. At a previous company we had to have a glossary of words that you could use instead just so the documentation made sense.
If the reason for this is that it's hard to change names, then the solution is to make it easier to change names, not to use stupid names. A given service should run on hardware/VMs that are named related to that service, and if the service goes offline, so does that hardware or those VMs, to be repurposed (and renamed) into something else.
Anything else leads to madness, or starts from madness.
I agree with this. Where I work, one team has given descriptive names to everything and several other teams have then shortened them inconsistently. So it's tribal knowledge that "cloud" and "gen2" are the same thing, and software/platform/gen1 are almost the same thing, but configured differently.
If we had called them Frank and Susan, we'd know what each other means.
> 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?
If your problem is that names are too descriptive, give your services a number. Because your naming fun will run out of steam, and it'll become cringy as heck when some engineer who thinks (s)he's funny assigns a cute name to a service that makes the rest of the company gag. It's quirkiness for the sake of showing off, not to solve a problem.
The purpose of naming things is to convey their meaning and character. By giving a non-descriptive name, one loses that potential. Please do not use cute names, unless there is really no good name to pick (like ad-hoc created docker container names, when --name is not specified). Give me information through means of naming things properly.
Does said argument have it's origins on here? I went to college with this guy (Assuming it's the same Nick Tietz) and thought it was satire, but I have no idea how people change over the years.
That or we're on the bleeding edge of Poe's law.
edit: It's far too early and my eyes skipped over the first sentence in the article.
So you have to remember all these random names matched up with their functions, memorizing all of it, because that is far better than one of them being misnamed and having to remember that the broadcast-service does something else.
When I worked at Twitter many services have bird names and some have descriptive names. The descriptive names are far better. Who wants to remember the user service is Gizmoduck?
Also, I don't know where this guy works that a service changes what it does over time.
At my company, we have an app called "rails app". It's the main app we have, and it's hosted in rails. Makes for some interesting discussions about what rails is truly capable of, what features are rails features or are rails features, etc.
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.
what a weird article... am I blind? where's an example of such "cute naming"? am I supposed to name everything AYAYA now? concise names aligned to business domain are worse because the way we think and responsibilities changes? wtf?!!
I worked for a company where everything was cute names with a particular outdoors theme.
All of the conference room names had the same theme. Starting out it was impossible to navigate if we were even talking about a product or a conference room etc.
nah, i'd stick with boring law firm names. people come and go and i don't want to inherit a project from john doe from 5 years ago that used a really obscure reference to gorean lore or some other "cute" names.
Names should be descriptive.
Cute names are an abysmal time sink.
Oh what does the quark service do? Who knows? Are there are 3 services named zoidburg? Oh well.
Service name’s are best when it roughly shares what it does.
I worked at a place where they named all of the systems and tools with puerile gross words. They thought it was cute. I thought it was a chore and also not easy to keep straight.
It sounds like this idea makes some sense in the context of having made a large number of mistakes already, but the real answer is, don't let it get that bad. The author strikes me as having worked only at companies that are so dysfunctional that they have never seen what a functioning team looks like.
It starts going downhill here:
> Trouble is, names are hard to change.
Uh, why? They shouldn't be. It should be a find/replace on text, with tests to catch any issues. The essay later goes on to talk about people using the name... but that doesn't matter, because the code is the self-checking source of truth.
Additionally, name changes should be rare if you did your job right the first time.
> A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing.
No. Wrong. A well-factored service has ONE responsibility. Period. Not "responsibilities", "responsibility".
This is what I mean when I say that a name change should be rare if you did your job right the first time. If a service has multiple responsibilities, you don't need to change the name, because you aren't adding or removing responsibilities. If you no longer need what the service does, the service can stop existing. And if you need something new, you create a new service.
And yes, sometimes performance means that you want to chunk stuff together, and strictly passing every different task over the network bus will cause your application to grind to a halt. That's more a criticism of the weird assumption that passing things over the network is necessary for encapsulation than of the single-responsibility principle, however. If your services are tightly coupled to separate network requests, you're going to experience pain no matter what you do. One of the first things a microservices architecture should do is abstract away the network so that from the caller's perspective, they don't know whether calling a service is making a network request or calling a library.
> 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.
Agreed, because a) broadcast-service is a pretty vague name and b) new-responsibility should be its own new-responsibility-service.
I like descriptive names that fade. It provides a sort of local etymology. Maybe not good for business, but definitly provides some interesting discussions at the pub.
Cute names often (not always) rely on a specific cultural context that many devs in the present, and definitely many devs five years down the line, won't share. When people argue for "cute" names over "descriptive" names, what they really often mean is "names that are actually descriptive but only if you understand my obscure nerd joke / spent your childhood playing pokemon". Or they pick a theme and end up trying to stick with it and make something vaguely, but not really descriptive within that theme. It also makes searching for internal documentation a nightmare.
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.
this is one of the designed benefits of hungarian notation, generating short, unique (not already overloaded) names that give a notion of type or class, and a distinguishing descriptor/mnemonic.
these terms can take on a memorable cuteness factor without being a sledgehammer of cuteness that crushes any notion of meaning.
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.
I agree. Right now I'm working on a service called simply 'backend'. We are adding some environment variables to it, and I'd like to prefix them with something relatively unique. BACKEND_DATABASE_ADDRESS is simply not unique enough to pollute the environment with. I know this example isnt perfect (and no were not even writing these env variables to the user's shell), but it demonstrates the lack of identity.
I usually do both. I'll have an easy to remember Code name followed by a descriptive name. This is to disambiguate the 700th TranslatingProxyLayer project. For example: ReliantRobin-DatabaseCleaner
Now when I search for it in a wiki or documentation I can find it easily, but people still know what the heck it is.
It seems to me that you have bigger problems than nomenclature. Do you add comments to your code? That's because you're part of a team. When you add function it should go in a separate package. Again, you're part of a team.
I agree with this 100% and have seen this play out many times. At one company we named the service “Harry” after one of the employees kid’s. Worked well, and I will fight for such names at any company I work at.
I couldn’t disagree more for service and infrastructure names.
> And I think this applies more broadly to projects and companies, too.
Customer facing names are fine, they should contain a bit of whimsy and cuteness. Obviously if you ship “payment-processor-gateway-v2” to the customer, that’s not a great name for a company, product, or feature. Projects also make sense (mostly), though they suffer from some of the same issues I’m about to outline.
However, for internal names like for services, adding cuteness is a horrible idea.
> A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing.
Descriptive names should help box in the scope of the service. If the payment processing service is also doing AI processing on user avatars, you might want to think about breaking that out into a separate service. With cute names, scope can grow infinitely because there’s no inherent description attached to the name. You may have “Athena” doing one thing but as things progress and the company/software grows, it’ll be taking on 17 other responsibilities. Instead if it’s named “backend” or “payment processor”, it’s clear in the name what it is and the scope of the project or service.
Then there’s the problem of an engineer’s mental overhead. Newcomers have to learn what all the cute whimsical names mean. You have to keep an internal dictionary and someone has to make sure it stays up to date. (Spoiler: It won’t ever be up to date.) I could have filled at least two pages with all the acronyms and whimsical names from one of my old jobs and it was always an ever changing landscape. If a service is named succinctly and clearly, the engineer doesn’t ever have to think about what that particular service is or does. I understand there’s going to be some edge cases where the name doesn’t cover everything, but that’s certainly better than the case where the name doesn’t cover any of the description of the service.
> It's impossible to predict with certainty how your software's requirements will evolve over time.
Then within the scope of the new requirements, changing the service’s name should be inherent in the discussion. IMO, this is a sign of some bad engineering processes. One shouldn’t be worrying about names in the future if you’ve named something correctly for the current scope. If it changes, address it then. Most modern languages will let you easily refactor a name. By those standards, you shouldn’t build the software, since it might change over time and we don’t want to make assumptions about whether we’ll still be using Mongo or if MYSQL makes a comeback. We can’t make those decisions because we can’t predict with certainty…you see the trap you can easily so easily fall into?
One thing that’s also a huge challenge is pronunciation. Someone will pronounce one of those cute names in a way that no one else has heard, it’ll take a minute to sort out, and, while it did get sorted, it took some time. Multiply that out over weeks, months, and years for every engineer and it can get costly. I understand that descriptive names can also be mispronounced, but since they’re common (to our industry), it’s easier to sort out.
I definitely do understand the sentiment behind adding some fun. I’m not here to kill the fun atmosphere of a new startup who wants to be cute about their names, but I’ve seen it play out very poorly over a long time when the company/projects/services/team grows and it’s not pretty.
Stick with descriptive names. You and everyone else will remember them easier and you’ll save time, giving you the time to go have some fun and grab a couple drinks with coworkers.
(I also published this here: https://memos.daviesgeek.com/m/4 for a little better formatting and to keep this comment around for myself)
I worked in a non-engineering role at a place that used cutesy names for almost everything: meeting rooms, engineering teams, internal tools and libraries, events. Nothing was descriptive, and even just fundamental roles and responsibilities were institutional knowledge. (They were "documented", but nobody was responsible for updating the docs when people left/moved/were added.)
So when a customer complaint about messaging came across my desk, I'd first have to figure out which team to go to: Ice Cream, Teddy Bear, Jetski, or Pineapple.
What parts of the product does Ice Cream work on? Do they work on the messaging protocol? Or was it the app server? Oh, didn't you hear, Jetski took on the app server last month and this week they're spinning off the messaging protocol into a new team, Applejack. Now Ice Cream's only responsible for user authentication.
Okay! Cool, so who's in Applejack? The Software Mage for the BrokenLighthouse library, which implements the messaging protocol? No, actually it's the Product Master for BrokenLighthouse's replacement, WorkingSignal. BrokenLighthouse maintenance is still with Ice Cream.
Okay! So is the Software Mage for BrokenLighthouse still on Ice Cream, like the directory (sorry, the Cast of Characters) says? No, they transferred to Jetski with the app server, sorry, I mean AppleBucket team.
Okay! I'll just join #jetski... wait, it doesn't exist anymore. Oh, right! Now that they have AppleBucket they renamed to Appleski.
Okay! I'll just join #appleski. (Damn it, Slack, don't autocomplete it to #applejack or #applebucket-feedback.) "Hey, I've got a support ticket for a messaging protocol issue, can someone help?"
> Sure, we're meeting in Batman on that right now! Come join us!
Okay! Where's Batman? The office has two floors, Cartoons and Comics, and each is divided into four themed quadrants, and each room is named after someone in one of those quadrants. So Cartoons is split into Adult Swim, Looney Tunes, Simpsons, and Disney, and Comics is split into DC, Marvel, Dark Horse, and Newspaper.
Counterintuitively, I loved watching Batman:TAS as a kid before I knew it was a comic book, so I always wind up wandering around WB looking for Batman. "Where's Batman?" Oh, Batman's in DC, upstairs.
Okay! I enter Batman and find Appleski talking about BrokenLighthouse.
"Hey! Is this where I can ask a customer question about the messaging protocol?"
Blank stares.
"Sorry. Is this where I can ask about this BrokenLighthouse error message that just says 'AppleBucket is refusing LightBeams from BrokenLighthouse due to a misconfigured PineappleSkin'?"
> Oh sure! That's just the message protocol saying there's a syntax error in the config YAML. The v2 protocol will switch to JSON and provide more detailed feedback.
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.
> 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.
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.
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.
I kept trying to tell people that the marketing name is going to change all the time and that the package we put it under should be very different from the marketing name - on purpose, so that we don't need to repackage it every 2 weeks. Call it com.companyname.dataintegrator. The marketing name of the data integrator can change all day long and its package must remain dataintegrator.