Names should be cute, not descriptive

https://ntietz.com/blog/name-your-projects-cutesy-things/

by dmarto • 4 years ago

351 478 4 years ago

cglong• 4 years ago

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.

ashton314• 4 years ago

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.)

doctor_eval6• 4 years ago

Yeah I nearly posted the same thing. We had a service called "petal" which did settlement - "settle petal" is a bit of Australian slang.

AceJohnny2• 4 years ago

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)

ilyt5• 4 years ago

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

jupp0r• 4 years ago

Just don't apply this to variable or function names please, thanks!

kleene_op• 4 years ago

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.

dottedmag3• 4 years ago

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.

duffmancd• 4 years ago

Reminds me of [0].

At work we tend to create backronyms for/from the cute names which is our way of having our cake and eating it too.

[0] https://youtube.com/watch?v=y8OnoxKotPQ&si=EnSIkaIECMiOmarE

PragmaticPulp• 4 years ago

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.

doctor_eval6• 4 years ago

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.

drstewart• 4 years ago

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.

ummonk2• 4 years ago

"policy-engine" is an example of a name that is neither cute nor descriptive

kzrdude• 4 years ago

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.

xorcist3• 4 years ago

A directory does wonders. Make it hierarchical too. That way different zones can have different values.

It can point "policy-engine" to which host runs it. Or, even better, make it resolve the IP address directly!

throwaway14356• 4 years ago

how else will you know they are new hires? They will have to spend time petting the fuzzBear just like everyone else!

jnsaff22• 4 years ago

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.

mostertoaster3• 4 years ago

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.

Macha3• 4 years ago

Homebrew is another project that overdoes it IMO

amiga386• 4 years ago

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, ...

wlonkly5• 4 years ago

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."

atoav3• 4 years ago

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.

nsonha3• 4 years ago

memorable name

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.

fiddlerwoaroof• 4 years ago

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.

mattigames• 4 years ago

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.

leeches• 4 years ago

Solved with company name or product name prefixes, like “discord-routing-service”

hooverd• 4 years ago

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.

atom_arranger2• 4 years ago

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.

nicbou• 4 years ago

https://youtube.com/watch?v=y8OnoxKotPQ&t=40

This is how it ends up sounding like.

ThePhysicist• 4 years ago

Came here to post this as well. It's exaggerated but only slightly.

ilyt5• 4 years ago

You need to do it anyway if your names are too descriptive*

"video-encoder is not working"

"oh, you mean ffmpeg"

"no, our microservice is called video encoder"

Also they are not neccesarily one or the other, you can name something that hints at its function but it is not straight dictionary description of it.

surement11• 4 years ago

"no, our microservice is called video encoder"

using cute names shouldn't be an alternative to learning to name things properly

wlonkly5• 4 years ago

Should've called it "video encoder service". Then people could refer to VES and you'd still have no idea what it was.

eps• 4 years ago

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.

alexvoda• 4 years ago

Kawai Wasabi is incompatible with Yakotori. It is a known choice by the lead developer.

When using Yakotori you should use Tare instead.

DaedPsyker• 4 years ago

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.

mrweasel2• 4 years ago

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.

avanai• 4 years ago

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.

wlonkly5• 4 years ago

Some of those have companies attached, which have interests in a unique, memorable, and protectable name. Others are definitely just cute though.

That said, I have to object to including linkerd. It links services together, and it's a daemon. Can't get much clearer than that.

andylynch• 4 years ago

Also becomes awkward and distracting having to explain to other peoples’ lawyers (or government officials!) what those cute names represent when things go wrong.

dclowd9901• 4 years ago

As an Amazon developer, I feel this. No wonder it’s so hard to get shit done.

JackFr• 4 years ago

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 have a soft spot for clever names, my favorite is still Leiningen the clojure build system: https://en.wikipedia.org/wiki/Leiningen_Versus_the_Ants)

nivenkos• 4 years ago

It feels like every company has an Apollo, Hydra or Hermes...

mook• 4 years ago

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.

nix-zarathustra• 4 years ago

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.

devnullbrain3• 4 years ago

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.

ShredKazoo• 4 years ago

Compromise: Come up with a cute name that vaguely suggests what the project does. E.g. instead of "broadcast-service", name it "Cronkite" or "NBC".

fckgnad2• 4 years ago

Nooo acronyms are horrible. When you have hundreds of services that are acronyms it becomes a nightmare.

feoren6• 4 years ago

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.

seti0Cha2• 4 years ago

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.

IshKebab• 4 years ago

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.

adrianmsmith• 4 years ago

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.

MichaelDickens• 4 years ago

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.

rikkuri• 4 years ago

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.

paxys2• 4 years ago

You really think a name is going to hold anyone back from this?

resonious• 4 years ago

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.

drewcoo• 4 years ago

I think code reviews might.

raydiatian2• 4 years ago

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

brianpan• 4 years ago

Don't forget about Galactus, the all-knowing user service provider aggregator.

https://www.youtube.com/watch?v=y8OnoxKotPQ

raydiatian2• 4 years ago

Okay so everything I said is apparently already a much more thought out rant

meindnoch• 4 years ago

This trend is so painfully cringey…

MrGilbert3• 4 years ago

I wouldn't necessarily call them cute, but "Odin" (my phone), "Tyr" (my NAS) and "Thor" (my home server) would surely agree.

knorker3• 4 years ago

Cute names don't scale.

You can name your servers after star trek characters, and routers after star wars characters, only if you have very few.

MrGilbert3• 4 years ago

Sure, yes - something that's not an issue at my home, but surely will at other places.

Regarding naming - Middle Earth should have many possible names at hand.

FeepingCreature• 4 years ago

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?

paxys2• 4 years ago

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.

extr• 4 years ago

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.

doctor_eval6• 4 years ago

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.

Naming is hard.

xlii• 4 years ago

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.

Naming is hard.

ilyt5• 4 years ago

That makes for easier, more transparent reading of error logs, the name "ServiceRouter", or the name "Trainstation"?

What service ? Routing it where? The "descriptive" here isn't describing anything useful.

"OrderBaseket" is descriptive. "sso-portal" is descriptive. "ServiceRouter" just uses few related words to the job. My blog is also "serviceRouter"...

gorgoiler• 4 years ago

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.

mastermedo• 4 years ago

When a bunch of those names accumulate, you pay a high onboarding price, not only for newcomers, but also for people who don’t read your changelog.

- Oh, _gfuby_ can now monitor my instance in production in addition to being a code versioning system!?

ppeetteerr• 4 years ago

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.

fexecve• 4 years ago

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.

lifeisstillgood• 4 years ago

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.

Directory services are way easier to manage

eyelidlessness• 4 years ago

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.

dopidopHN• 4 years ago

Whatever, but just don’t use starwars or Marvel names.

knorker3• 4 years ago

Cute names are awful.

What, you don't remember every Star Trek character? What, you can't spell every Greek philosopher?

Really, you don't know which are star names and which are galaxy names?

And then there's the reuse. Which project mayhem is this?

beshrkayali• 4 years ago

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.

godelski2• 4 years ago

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.

kqr3• 4 years ago

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.)

Macha3• 4 years ago

Brew tries this:

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.

kqr3• 4 years ago

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.

gwhl• 4 years ago

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.

Izkata2• 4 years ago

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.

noveltyaccount• 4 years ago

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.

grahar647• 4 years ago

Great idea!

ptr• 4 years ago

Since services are basically modules in monoliths, does that mean that we should have cute names for those as well?

lemper• 4 years ago

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.

germanfella• 4 years ago

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?

pprotas• 4 years ago

I’m sorry but I just have to link this classic video, this comment reminds me of it: https://youtu.be/y8OnoxKotPQ

nextlevelwizard• 4 years ago

Sounds more like architectural/tooling problem.

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.

28304283409234• 4 years ago

I heard that Ifthingsaredoneright is a really nice planet to visit one day.

Gigachad• 4 years ago

Doesn’t sound like that would be any easier with different names

jeroenhd2• 4 years ago

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.

xeyownt3• 4 years ago

Couldn't have said it better.

Overall, common sense should be the rule, not "always descriptive / always cute".

Draiken• 4 years ago

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?

danparsonson3• 4 years ago

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?

Do you really think that

user-provider-service, timestamp-conversion-service, image-storage-service

is no easier to follow than

bulbasaur, charmander, squirtle

? After ten minutes of 'eevee depends on charizard, which in turn requires mewtwo' I would be utterly lost.

gilbetron3• 4 years ago

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"!

danparsonson3• 4 years ago

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?

eYrKEC2• 4 years ago

What if this is survivor-bias?

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.

geysersam• 4 years ago

This problem is quite interesting from a theoretical point of view.

How to structure a program to be less dependent on its name?

Would it be possible to have a single source of truth for names? So that if you want to change a name, that's a single line commit.

Problem is, if the name is dynamic we'll have to refer to the name using another name.

styluss• 4 years ago

having worked in a company where project were named after marine life, I changed my mind, no cute names.

tgv2• 4 years ago

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.

bobbiechen2• 4 years ago

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

pbnsh• 4 years ago

Was that company by any chance founded by a rick roll sent via an api/sms and has 4 dots in it's logo?

bobbiechen2• 4 years ago

Yeah, it's Twilio - my profile here is easily connected to my work history haha.

kstenerud• 4 years ago

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.

Lapsa2• 4 years ago

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?!!

jnsaff22• 4 years ago

Dude(tte) is losing an argument so they turn to HN for more arguments by writing a trollish blog post.

I find naming to be one of the most bikeshady of activities.

Pick something and move along. The more you think/argue about them the worse the outcome.

Channel your first instinct but be ready to change it once it turns out to be wrong.

fein• 4 years ago

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.

mostertoaster3• 4 years ago

Wrong answer.

Names should be cute AND descriptive.

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.

pipeline_peak• 4 years ago

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

sublinear• 4 years ago

I only agree if I'm allowed to reinterpret "cute" as easily recognized uniqueness.

The motivation for cuteness seems to be a spiteful false equivalence made between unintentionally bad names and deliberately silly names.

Good names come from well organized projects.

It's sad to hear some would rather name their servers after dolphin species than address the communication problems on a team.

r_hoods_ghost• 4 years ago

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.

dbingham2• 4 years ago

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.

Hermitian909• 4 years ago

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.

dbingham2• 4 years ago

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.

ilyt5• 4 years ago

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

grahar647• 4 years ago

If you work at a company for more than a week you will get used to the names of services and what they do.

But if the name of a service becomes a lie because of changing requirements, then it will be an actual hinderance to understanding a system.

pvsnp• 4 years ago

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.

Towaway69• 4 years ago

My approach is cute or funny names based on abbreviations, e.g.:

- trump - totally reversible universal manipulation protocol

- Biden - booked Internet device expense network

That way a cute name has a meaning. Additionally one can change the abbreviation if the purpose changes!

nirui• 4 years ago

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.

cbeach• 4 years ago

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.

SideburnsOfDoom• 4 years ago

Title is wrong, should be "Thank You Mario, But Princess Peach Is in Another Castle!"

If you disagree with that, then maybe you are in favour of descriptive, not cute, names after all.

I really thought that we had moved past this "cute pop culture reference naming" idea, but here it comes back again. Just no.

Xorakios• 4 years ago

When the name is public-facing rather than internal, cute is better because it's better suited for trademarking.

rk06• 4 years ago

Why not have two names? Canonical (descriptive) and a code name for referring.

I am all for Descriptive names, but they tend to be long and hard for uninitiated to pronounce or remember correctly

nzach2• 4 years ago

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 names don't mean anything. And if you do know you still have to guess what the the service does.

[0] https://en.wikipedia.org/wiki/Freyja

[1] https://en.wikipedia.org/wiki/Metis_(mythology)

ilyt5• 4 years ago

Metaphors don't qualify for cute but descriptive, there is nothing descriptive about it.

bryanrasmussen3• 4 years ago

I still don't get why Freyja would have something to do with a shopping cart?

nzach2• 4 years ago

If I remember correctly it was because she rode on a cart.

andy_ppp2• 4 years ago

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!

surement11• 4 years ago

just name things with single letters and when you run out you can use double letters etc.

you'll be so fast at writing code a promotion is sure to follow

contravariant• 4 years ago

Contrarian take:

If your code is unreadable with single letter variable names your comments aren't clear enough. Case in point: Mathematics.

weitzj• 4 years ago

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:

https://youtu.be/y8OnoxKotPQ

jonstewart• 4 years ago

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.

jrib• 4 years ago

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".

beefield• 4 years ago

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.

andy_ppp2• 4 years ago

Yes, some places I’ve worked named servers with four numbers separated by full stops, it was crazy!

quickthrower22• 4 years ago

Even better if they are in the 0-255 range but different from the IP addresses they are using!

deltarholamda2• 4 years ago

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."

tremon2• 4 years ago

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.

Sholmesy• 4 years ago

I've never disagreed with something more.

On the other hand, something that's cute will be far more memorable and much easier to say.

Citation needed?

How is <random-fairy-dust-word> easier to associate with "Ingest, Processing, & Storage of Thing" than <thing-etl-service>?

EDIT: On closer inspection, I think this is intentional HN rage bait.

surement11• 4 years ago

EDIT: On closer inspection, I think this is intentional HN rage bait.

do flag stories like this

xvilka• 4 years ago

Or use names of Lovecraftian deities. It better resembles the spirit of the industry.

Shank• 4 years ago

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.

ChintanGhate• 4 years ago

Go for boring descriptive names that create a cute acronym. Win-Win!

quickthrower22• 4 years ago

I disagree because if your machine learning service, Rudolph, has become a load balancer, you have bigger problems!

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.

throwawaaarrgh2• 4 years ago

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).

Aaargh20318• 4 years ago

The author is not talking about the individual parts though, they are talking about entire services. So basically products or maybe large modules.

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

throwawaaarrgh2• 4 years ago

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)

bmitc8• 4 years ago

I could not disagree more.

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 <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”.

michaelmior• 4 years ago

> Trouble is, names are hard to change.
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.

hgomersall• 4 years ago

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).

tialaramex• 4 years ago

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".

pmelendez• 4 years ago

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.

andrelaszlo• 4 years ago

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?

formerly_proven• 4 years ago

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.

surement11• 4 years ago

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

code that's hard to change or delete is bad code

cfuendev• 4 years ago

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?

causi• 4 years ago

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.

lo_zamoyski2• 4 years ago

Try discussing Elastic Beanstalk around non-dev coworkers.

Labels can obscure and obfuscate as much as they can reveal. One must ask what the badly named thing is. What does it do?

taneq2• 4 years ago

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.)

Spivak4• 4 years ago

Well yeah because those things are all specific implementations of services. They need to have unique names for preciseness.

"Oh yeah we've moved our app processes into containers which we manage with our workload scheduler and discovery service."

What is the app? What kind of containers? What kind of scheduler? What kind of discovery service? Guess you just have to know. Verses.

"Oh yeah we moved our frontend Rails processes into Docker containers which we manage with Nomad and Consul."

afarrell2• 4 years ago

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.

BlueTemplar• 4 years ago

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.

xeyownt3• 4 years ago

I guess the point is to give cute names to things that will last years and have a large scope, not to every variable in your code.

surement11• 4 years ago

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.

Pietertje• 4 years ago

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.

gilbetron3• 4 years ago

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.

bmitc8• 4 years ago

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.

JoBrad• 4 years ago

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.

seti0Cha2• 4 years ago

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.

superb-owl2• 4 years ago

Trouble is, names are hard to change.
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.

bmitc8• 4 years ago

We're talking about software service and component names. Not names in general or company names.

pjc50• 4 years ago

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.

whoisthemachine4• 4 years ago

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.

Spivak4• 4 years ago

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.

yokoprime• 4 years ago

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

gnull• 4 years ago

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.

GuB-42• 4 years ago

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.

discreteevent• 4 years ago

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.

threatofrain• 4 years ago

Really not sure this works for homebrew with their brew and tap and keg naming theme.

bumby2• 4 years ago

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.

civilized• 4 years ago

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.

perrygeo• 4 years ago

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.

starkd• 4 years ago

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.

Scubabear68• 4 years ago

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).

crispyambulance• 4 years ago

...software engineers cause their own problems

yep. I once inherited a bunch of C++ applications in which the class hierarchies were named after Lord of the Rings characters. FML!

ImPleadThe5th• 4 years ago

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.

bmitc8• 4 years ago

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.

dogleash• 4 years ago

Why are software engineers like this?

They're not. Some are.

Others are dead set on no cutey names. Causing people in their vicinity go around asking "why are software engineers such sticks in the mud?"

They're not. Some are.

grahar647• 4 years ago

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”

gloosx2• 4 years ago

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

mattlondon• 4 years ago

No no no no no. Please never ever do this.

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.

vvillena• 4 years ago

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.

MayeulC• 4 years ago

Well, if you change the role of a named thing, change the name too. The role change is probably breaking many assumptions already.

You can also keep the old name around as a stub to talk to the new one, if needed (like during a transition period where it becomes deprecated).

heavenlyblue• 4 years ago

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.

bryanrasmussen3• 4 years ago

so are the names master and slave originally meant to be cute or descriptive, and how did that work out for everyone?

abram• 4 years ago

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

harryvederci• 4 years ago

I agree, it would be much better if the article url would be

    ntietz.com/puppy/cuddles-and-teddybears

micro_charm• 4 years ago

Feel like this article was intentionally written to validate Cunningham law and to promote bikeshedding. It's an almost perfect trap for that

wellpast• 4 years ago

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.

amarant• 4 years ago

Surely this is satire.... Right? Right?

Lapsa2• 4 years ago

has to be

AYBABTME2• 4 years ago

How about making them descriptively memorable:

    - shifting-priorities-routing-service
    - indiscrete-secrets-vault
    - gdrp-user-immolator
    - knock-knock-whos-this-authn
    - canihaz-authz

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.

xeyownt3• 4 years ago

The advantage of making cute is that you can also make them small.

I would really hate using shifting-priorities-routing-service all over the place, in particular in combination with steady-allocating-routing-service.

Between cute/descriptive, long/small, it all depends on how often/where/long these names are used.

AYBABTME2• 4 years ago

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`

Tangurena2• 4 years ago

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.

surement11• 4 years ago

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.

carlosrdrz• 4 years ago

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!

ryanjshaw• 4 years ago

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

Arch-TK• 4 years ago

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.

shp0ngle• 4 years ago

What’s a better name. “Epiphany” or “GNOME Web”?

Everyone calls it Epiphany anyway.

So yeah I agree.

brabel• 4 years ago

The argument has convinced me, even though I thought it was crazy, initially.

Very good points and for many things, I think this applied very well.

reassembled• 4 years ago

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.

dctoedt2• 4 years ago

I recall reading that such use of trademarks for internal code names led to legal issues for a company.

Apple Macintosh, perhaps?

https://www.macworld.com/article/669214/how-the-macintosh-go...

nibbleshifter• 4 years ago

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.

xcambar2• 4 years ago

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.

tabreu2• 4 years ago

This. Balance is key imo.

grahar647• 4 years ago

Yes, and we should change an entire companies culture to make a new hire onboard slightly faster /s

surement11• 4 years ago

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

xcambar2• 4 years ago

In this occurrence, I couldn't measure the benefits of that specific element of culture.

It may have been silent and powerful, I'll spare you the extra comment ;)

jagged-chisel• 4 years ago

Names are hard to change.

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.

deafpolygon• 4 years ago

Says names should be cute. Does not offer cute name in article.

code_runner• 4 years ago

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.

fragmede2• 4 years ago

Three great unsolved problems in computer science are naming things and off by one errors.

tabreu2• 4 years ago

I love this.

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.

eliasffyksen• 4 years ago

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.

jraph• 4 years ago

The more I read about this topic on HN, the more I have a strong opinion that I should not have a strong opinion on this.

(I'm for cute AND descriptive though)

(and somewhat not against anything, unless things too generic like "Web" or "Internet Explorer" for a browser or "File manager" for a file manager)

xtiansimon2• 4 years ago

Funny trifle.

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.

Naming is hard, but also fun.

tremon2• 4 years ago

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.

xtiansimon2• 4 years ago

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.

dudeinjapan• 4 years ago

So... why did the author give this blog post a descriptive title? Wouldn't a better title be "Fluffy Bunny"?

fedeb95• 4 years ago

yes, piling up dust under the carpet could have a cute name. You don't want to pile it in the first place though

btbuildem• 4 years ago

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.

surement11• 4 years ago

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

thenerdhead• 4 years ago

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.

hawski• 4 years ago

I'm afraid it would be tmp and tmp2.

zelphirkalt• 4 years ago

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.

tauwauwau2• 4 years ago

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.

The ntietz entry is talking about using cute names for internal services, which is very bad idea. Please enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ

m_mueller• 4 years ago

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).

leokennis• 4 years ago

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?

Or is your company now going to have you order your staples through "https://papersupplier.acme.com"?

We all know it's the second.

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.

tauwauwau2• 4 years ago

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.

kpz6• 4 years ago

I don't want my services or projects to sound like a law firm ("Ingest, Processing, & Storage LLP").

That would actually be a fun name.

andix• 4 years ago

So how do you call your services? Harry, Ron, Hermione and Voldemort?

sixstringtheory• 4 years ago

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.

thedorkknight2• 4 years ago

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

I'm not sure I see the point

toomanyrichies3• 4 years ago

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.

salawat• 4 years ago

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.

surement11• 4 years ago

It's worse than being non-descriptive- it's that they become misleading.

if you find that something has drifted to the point of being misleading, then rename it

it's software not hardware

or comment on code reviews that change the functionality to the point where this is a problem

thedorkknight2• 4 years ago

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

stiiv• 4 years ago

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.

nightowl_games• 4 years ago

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.

suyash• 4 years ago

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.

whoisthemachine4• 4 years ago

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.

lioeters• 4 years ago

..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.

whoisthemachine4• 4 years ago

We call these tractors, although the adapter is usually on the rear! And I think they are gaining some AI.

Waterluvian• 4 years ago

Help me, for I am socially malnourished. This is a joke, right?

eckesicle• 4 years ago

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.

desio• 4 years ago

Wish I read this before I named gonna my dog "Noise Maker".

djmips• 4 years ago

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.

the_af• 4 years ago

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.

jfoster• 4 years ago

I can't prove anything, but I have a feeling that this article was intentionally written to be annoyingly wrong in order to generate engagement.

hcarvalhoalves• 4 years ago

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").

jacknews• 4 years ago

LOL, is this sarcasm?

Perhaps we should copy science and maths and name services after their developers:

  chet-obagdu-braithwaite server
  peyton-garcia endpoint
  murata-checkov service
  somerstein API

etc. LOL.

secondcoming• 4 years ago

Giving things cutesy names is hardly inclusive behaviour, especially for those who don't speak English as a first language.

once_inc• 4 years ago

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.

mnw21cam• 4 years ago

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.

grahar647• 4 years ago

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.

arichard123• 4 years ago

Are we short on good words to describe the moving parts of our systems? We use so many synonyms for "thing" that then get overloaded.

Do we not just need to invent some new words with specific and useful meanings?

I'm not sure where the different lines would be drawn. Perhaps thinking about a specific program might be helpful. This can't be new thinking can it.

What naming conventions do people use that aren't obvious but are useful?

grahar647• 4 years ago

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.

trimethylpurine• 4 years ago

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.

__MatrixMan__• 4 years ago

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.

surement11• 4 years ago

if your solution to overly generic names is names that are meaningless without context, you probably have bigger problems

stared2• 4 years ago

Let's go further:

Function (and class) names should be cute, not descriptive. It is impossible to predict how these evolve and change their names.

devnullbrain3• 4 years ago

The mirror to this argument is that company names should also be descriptive. Goodbye Amazon, hello OnlineBookStore.

stared2• 4 years ago

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).

jxf• 4 years ago

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.

sesteel• 4 years ago

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.

foxyv• 4 years ago

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.

rhacker2• 4 years ago

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.

joelthelion• 4 years ago

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...

kmac_• 4 years ago

Of course everybody knows what Galactus does!

fckgnad2• 4 years ago

I disagree. But cute is better than a fucking acronym. Never never never use acronyms or one letter variable names.

gloosx2• 4 years ago

My favourite:

status: Enum<0,1,2,3,4,5,6,7,8,9> // 0-kitties, 1-puppies, rest in Confluence

eightturn• 4 years ago

i guess I'll just let VidaliaOnions.com expire then ... :/

themoonisachees• 4 years ago

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.

xorcist3• 4 years ago

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.

twawaaay• 4 years ago

I think names should first of all be reliable.

What I mean by reliable?

* 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.

kevincox2• 4 years ago

Your list is very similar to mine: https://kevincox.ca/2021/03/23/good-names/

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.

rhacker2• 4 years ago

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.

kevincox2• 4 years ago

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.

pphysch• 4 years ago

It seems that most business objects should have all of the following:

1) A memory-friendly, indexed, unique, immutable ID (e.g. BIGINT or GUID).

2) A human-friendly unique immutable codename/slug.

3) A human-friendly mutable marketing/display name.

1 & 2 could be combined in some cases

dlivingston3• 4 years ago

Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView).

https://developer.apple.com/documentation/appkit/nsview

wruza• 4 years ago

I mostly agree, although from a user side it’s sometimes confusing to encounter random identifiers barely mentioned anywhere.

jcampbell1• 4 years ago

Last time I did iOS stuff, coding around iCloud everything was called UbiquityContainers or something.

dottedmag3• 4 years ago

It requires discipline and good review practices to consistently use either marketing or technical identifiers in any given layer, including UI and API.

aendruk• 4 years ago

I tried this once and marketing latched on to my deliberately stupid code name and used it for the public release. My protest was unable to sway them.

dlivingston3• 4 years ago

If comfortable disclosing, what was said code name?

pengaru• 4 years ago

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.

banku_brougham3• 4 years ago

This is not an effective argument in disagreement with the OP.

layer84• 4 years ago

I don’t think it was supposed to be, given the introductory “while”.

WuxiFingerHold• 4 years ago

I agree in that the need to refactor large amounts of code because of changes in the marketing product name is insane.

If the devs had just ignored the change the first time (kept the name integrationhub) the separation would have happened naturally.

Scea91• 4 years ago

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...

dottedmag3• 4 years ago

I do. In my current project there is a rule: if marketing touches it, it's not a name, it's a label.

Starting from the code repository and down to the variables names, only technical identifiers are treated as stable.

danmur• 4 years ago

Yep. All my personal projects I give a name that's related to the subject but will never be a public name. Helps a lot with naming paralysis.

AlanSE• 4 years ago

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.

Hani1337• 4 years ago

Why not both? Do it like counterstrike maps with their gamemode prefix de_ cs_ kz_ surf_

host_dandelion01, client_pollen01, merger_fusion, compiler_compost_v1, etc

cosinetau• 4 years ago

Got a cute name for this: bikeshedding.

discordianfish• 4 years ago

(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.

erikpukinskis2• 4 years ago

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.

kodah• 4 years ago

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.

jkingsbery• 4 years ago

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.

erikpukinskis2• 4 years ago

There’s some history here people are missing.

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.

nix0n• 4 years ago

I agree that this makes sense for boxes.

we named them Athena, Zeus, etc

The bonus of this kind of theming is that if someone mentions a Greek god you know they probably mean a box.

One reason this makes more sense for boxes, is that a box will have features and responsibilities taken away more than a program or service will.

If a service is named according to what it originally did, even though it took on additional responsibilities, that's fine.

bfung• 4 years ago

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.

plank• 4 years ago

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;-)

scruple• 4 years ago

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.

athenot• 4 years ago

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.

AtlasBarfed2• 4 years ago

... that implies all your services already were HTTP-separated or some other swappable network invocation besides direct calls ...

Which means... you were microservicing before microservices were a thing?

If not, do you care to share how you abstracted your service invocations so they could fluidly go from inter-box comms to separated boxes?

marcosdumay4• 4 years ago

Network services were port-separated since the internet was a thing. (A bit earlier, but ports had different names.)

franga2000• 4 years ago

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.

trynewideas2• 4 years ago

There's a decent middle ground where the cute name is also descriptive, even if it's indirectly so.

For instance, Grafana's stack is

Logs

Graphs

Tracing

Metrics

so their services are

Loki

Grafana

Tempo

Mimir

which also spells "LGTM".

Of course, then they shipped "Phlare" because apparently they couldn't find a cute name for Profiling?

feoren6• 4 years ago

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?

shkkmo3• 4 years ago

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.

[0] https://en.wikipedia.org/wiki/Michel_Eug%C3%A8ne_Chevreul

feoren6• 4 years ago

first mentioned by an alchemist

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.

serverholic• 4 years ago

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.”

kerkeslager4• 4 years ago

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.

feoren6• 4 years ago

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.

daviesgeek• 4 years ago

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)

furyofantares• 4 years ago

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).

kerkeslager4• 4 years ago

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.

throw__away73915• 4 years ago

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".

jakelazaroff4• 4 years ago

If you're going to do this, why not also do it for classes, function, and variables?

Because those are easy to change. Service names inevitably get strewn across who knows how many other services and pieces of infrastructure.

throw__away73915• 4 years ago

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.

zffr• 4 years ago

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.

TylerLives• 4 years ago

The difference is that a service might do many things, while functions and variables usually have smaller purpose.

throw__away73915• 4 years ago

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.

layer84• 4 years ago

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.

wvenable2• 4 years ago

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.

banku_brougham3• 4 years ago

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.

jxramos• 4 years ago

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.

unbalancedevh• 4 years ago

the very worst name you can give any product is "Atlas"

I always thought the worst name was "Next Generation ...", which quickly becomes kind of silly when it's time for the revision after that.

trynewideas2• 4 years ago

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.

dctoedt2• 4 years ago

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.

Self-cite: https://www.oncontracts.com/startup-law/#Trademarks_look_for...

Usual disclaimer: I'm a lawyer but not your lawyer.

atom_arranger2• 4 years ago

Could not disagree more.

ryanmcbride• 4 years ago

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

cryptonector• 4 years ago

Names of products should be memorable, and probably cute.

Names of technical items (e.g., function names) should be descriptive.

anchochilis• 4 years ago

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!"

allknowingfrog• 4 years ago

I have this exact regret. Code may be meaningless, but acronyms are both meaningless and confusable.

lamontcg• 4 years ago

This is a good example of negativity bias.

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.

ppqqrr• 4 years ago

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.

imwillofficial3• 4 years ago

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.

spullara• 4 years ago

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.

sirsinsalot2• 4 years ago

I refuse to ever use homebrew because all the themed naming makes me rage.

It is nonsense.

kdamica• 4 years ago

IIRC at one point at Uber there were three completely separate services named Polaris.

bsima• 4 years ago

Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

Does Sam's last name happen to be Smith or Cooper or any of the other thousand of occupational surnames people use? Just curious..

imwillofficial3• 4 years ago

I worked on a service called the Bill Auditor Service. When people wanted to find out who, wait for it, audited the bills, they knew where to go.

And sure we had some services where their name no longer reflected their purpose.

Those were refactored and renamed when the time was right.

shove• 4 years ago

thats-bait.gif

ChrisArchitect• 4 years ago

Naming is one of the hardest things in computer science of course....

..but also one of the most fun!

janef0421• 4 years ago

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.

ram_rar• 4 years ago

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.

pwinnski• 4 years ago

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.

tastysandwich• 4 years ago

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."

wlonkly5• 4 years ago

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".

fsckboy• 4 years ago

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.

nazka• 4 years ago

This is really AWS naming vs GCP naming.

nathan_gold• 4 years ago

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.

allenng• 4 years ago

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.

Names should be cute, not descriptive

Related Stories