121–130 of 498 posts
The worst is when cute meets descriptive. 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…
You can create a new service to do the new thing!
IaC might make it easier to rename stuff anyway but not everyone does that.
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).
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.
Yes, some places I’ve worked named servers with four numbers separated by full stops, it was crazy!
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.
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.
Earlier quoted context omitted.
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.
I'm going through it right now, refactoring https://humungus.tedunangst.com/r/honk honk, zonk, honker, dunk, xonk... the list goes on. This is supposed to be ActivityPub server. Fun. Not.
> Trouble is, names are hard to change.
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 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 ” because it doesn’t just do . 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”.
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 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 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/purp…
To use your car analogy: It's the Ford Mustang, not the Ford goes-really-fast-as-long-as-you're-not-taking-any-corners-sporty-car