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.

So I think policy-engine might have seemed descriptive but it just wasn't whereas image-optimization-engine was descriptive.

Very few times somebody starts something like this. And yes, they do have cute names, because they don't have any short identification.

No, there's 5 different directories in 3 different formats compiled across the last 8 years representing the state of 80% of terms at the time it was last updated, half of which disagree with another version.

Nevertheless, the same phenomenon that leads to multiple directories will also mean that supposedly "descriptive" names, will not be.

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

And if the junior doesn’t know the story of little red riding hood, well then it is your lucky day and you are one of the 1 in 10000 who gets to tell them the story.

Then when things go off the rails, I can say 'Shaka, when the walls fell'

Darmok and Jalad at Tanagra.

Chef = a configuration management tool

Recipe = an individual Ruby script that makes sure something is installed and configured correctly (e.g. a mysql recipe)

Cookbook = a bundle of recipe(s) and basic metadata (what do these recipes do, who wrote them, etc.)

Supermarket = a community site with common cookbooks, what others would call a "hub", "central repository", "marketplace" or "store"

knife = a command line tool for managing your chef installation

Test Kitchen = a test suite runner

Cookstyle = a code linter

However, now that Chef has gone full Enterprise (never go full Enterprise), the names are now all enterprisey-sounding: everything is "Chef XYZ", e.g. "Buzzword you know + Buzzword you don't", harnesses the CxO's FOMO. Chef Habitat = write declarative rules for applying cookbooks to machines. Chef InSpec = auditing/compliance. Chef Workstation = what you would have normally installed anyway, the development kit and runtime tools, but now it's EnTeRpRiSe, ...

It's written on the wall for Ansible, Red Hat/IBM is busy churning out the product space already.

It's weird that there's so much money in enterprise IT. If anything, they should know the value of standards and reference implementations.

Almost 25 years ago, SSH went full enterprise and promptly died. Somehow, they need for a simple remote shell protocol didn't die, and now OpenSSH is perhaps the most valuable tool we have.

There are other, less silly, but equally memorable (and maybe even cute) descriptives out there.

On a different note: if you are presented with an either/or choice, your first instinct should always be to ask if they are actually opposites or if you can also have both if clever.

is it ever a problem in software engineering, that you can't remember what that component's name is?

I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, their lib would not even come up.

Yes. When the names are descriptive or bland, it's almost impossible to remember what it is.

This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.

What I agree with is that it is not strictly necessary, but that is a label that you can stick on a lot of things. Things that make our lives easier. Memorability of names is not a necessity in software engineering, just as is descriptiveness, but it certainly does not hurt.

An old name made of well-known technical words can easily suggest a level of complexity much smaller than what it has evolved into and therefore developers -specially new devs- should look it up instead of assuming what it does based on potentially misleading namings.

This is how it ends up sounding like.

"video-encoder is not working"

"oh, you mean ffmpeg"

"no, our microservice is called video encoder"

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

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

When using Yakotori you should use Tare instead.

Something like coffeescript is at least distinct but then you get a hundred things that will be called something like apple juice, based on some in-joke connected to a stack that will be called orchard.

And at a conference, you'll have two animated people arguing over the use of...well...I didn't quite get it, it was loud, but it was the solution to all things and I'll never find out what it was, because what I _thought_ I heard was Spogdog, but Google's got NOTHING.

(If only I knew it was SpŌgDog)

It's this needless layer of jargon that doesn't help with the understand of the solution.

Sure, if there's a reasonable chance that your project becomes absolutely massive, then a unique name is a great idea. For internal project, don't be cute, just call the thing by its function. Your warehouse management system should just be "the WMS", not FluffoTron. Should it happen to take on new functionality, then either split that out in a separate project, or just rename the whole thing.

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

I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and generic and not terribly uncommon end up being the worst.

(I have a soft spot for clever names, my favorite is still Leiningen the clojure build system: https://en.wikipedia.org/wiki/Leiningen_Versus_the_Ants)

I managed to avoid creating any new tools or services with bird names during my time there, though it was tempting to do so.

Reading documentation is not a bad expectation of a developer.

Now imagine trying to navigate hundreds of things that are descriptively named wrong. The argument isn't between (A) cutesy names, and (B) accurate descriptive names. B is obviously better. But that's a fantasy world that doesn't exist. The argument is between A and (C) descriptive names that rot over time (quickly or slowly), which is actual reality.

Yes it might. But it probably won't, or it will be obviously outdated, or outdated in trivial ways or you can use Git blame to check how the code was when it was written. All of which is better than no comments 99% of the time.

The number of times I've read a comment and eventually thought "oh damn that was misleading, I wish that comment wasn't there" is like... 10 in my whole life.

The number of times I've thought "why does the foo-service also do bar? I wish they'd named it completely randomly instead" is precisely zero.

I wonder if that's the point, and why certain people use weird names for things. They're senior engineers, they get a nice salary, it's rational (albeit not in the interest of their employer) to prevent their job getting taken over by a junior developer. So they have to set up roadblocks, moats, barriers to entry etc., and weird service names are one such barrier.

In general team members are going to look after their own interests (e.g. set up roadblocks), but if this sort of stuff goes on it shows bad engineering leadership within the company, as it's the leadership's responsibility to stamp down on this sort of behaviour.