Names should be cute, not descriptive

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?

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

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

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