Yes. The advice is contextual. If you're making a public web framework, probably don't call it Web Framework. If you work at a company and you're writing the one and only hotel booking service, do call it Hotels instead of forcing your coworkers to memorize yet another cute name.

This only works once though.

In ten years, none of the original developers of Hotels are with the company. The new generation of engineers is upset both with Hotels’ limitations and the fact that it’s not written in XYZ language which they really want to have on their résumés.

So they embark on a total rewrite of Hotels, and to emphasize the awesomeness, most likely it will be called either Phoenix (because one out of three internal 2.0 rewrite projects is called that) or Venice (because it’s a place that has lots of hotels).

As part of their ambitious rewrite, they also start building a custom message queue in XYZ. It’s called Milan so there’s now a cute city theme. A bunch of other exciting NIH XYZ greenfield projects spring up, all with city code names.

Another ten years go by. A programmer complains to another:

“Where I work is the worst. There’s all these projects written in XYZ which nobody uses any more, and they’re all named after random cities. Why couldn’t they call the hotel booking service something descriptive.”

I solve that by naming my greenfield projects "hotels_old" from the get-go. It makes things easier for the next guy who replaces it.

Its something that works in the cloud on a server. Its a cloudcomponentprocessor. Thats exactly what it is, what it does and absolutly context free.

Descriptive alone does not cut it.

Bonsupoints if your software throws errors, that throw customers. "I want to book a flight to NY, but it keeps saying Venice:DB is full"

They can also name it Hotels2. It's up to the people what they name it, some like cute names, some the descriptive.

I know! Hotels-rs

My company has been throwing `-ng` on all the new versions.

Until that's expired. project-ng-ng? (I know the pain, we did the same thing at work).

No, `project-ds9` is the obvious upgrade path.

They included the "the" in placed I've worked. project-tng

project-picard

enterprise software at its finest

`-ng+`, `-ng++`

What’s ‘ng’ short for? Next generation?

How about just Hotels 2.X.X.X? Honestly, not much reason it can't be the exact same namespace depending on the language and whether the new and old would be imported by the same project.

If someone doesn't like something, they may criticize anything about the thing, such as (a) having or a silly name or (b) having a generic descriptive name. Sometimes you just can't win. Sometimes such 'spillover' criticism is better understood as collateral damage from deeper frustrations.

I can easily imagine the conversation after everyone has started using Hotels to book meeting rooms as well, so I think this is an argument for the other side. :)

I don't even use Serverless Framework that often yet get irrationality annoyed at how generic a name it has.

I opt to compromise and use middle ground name, which both related and fun.

A tool for sending mails via Mailgun? “Railgun” then, for example.

This is my stance. 2 words: Memorable Use.

Banana Cache

Hadouken Security Service

Lightfoot Containers

I mean, this is pretty much the AWS formula.

For bigger services, it makes sense. For smaller utilities single word names are better IMHO.

I'll keep this formula in mind too, and use it when I develop something bigger.

This is the right middle ground imo as well. It adds a bit of simple difference between the 15 different exporters, without being too far off. We have things like the "Tenant Saw" - extracts a tenant from a multi tenant system, or a foosystem-butler called Vlad - automating and scripting a bunch of busywork around the foosystem.

> Cryptic names are horrible. It's a layer of cognitive overhead that no one needs

I disagree with that. Cryptic names can become jargon, and jargon is useful in expert teams. At my last job we had a service whose role was to convert operations from system A to system B so at first we named it systemAOperationsToSystemBOperations. The name was clear but it was a pain in the ass to talk about it. We renamed it adios as a shorter name (irks like a fake acronym of the initial name) and it became way easier to talk and reason about our system. We lose a few minutes once in a while to remind juniors what adios does but we gain an efficient name to discuss the service day to day.

It says "component". How many components do you have? I suppose if need to deal with more than a dozen components simultaneously, something is wrong. What is worse, the overhead of maybe not knowing a one-word description of component FancyName once in a while (so you have to look it up, pressing F12 or such), or having to deal with a obsolete, too long name (trying to be clear, or having too disambiguate between multiple redesigns), or unfitting name: all the time you're working with the thing?

Screens are huge now. You can fit long names. Auto complete makes typing long names easy. Let your code read like prose. Save the brain for solving the business problems not for understanding the code.

Long names are easier to read the first time, and become an impediment thereafter. Especially when you have multiple long names that differ only in a few characters.

Not really. Screens are wider. An older 21 inch was taller than a 24 inch tft

The point is that descriptive names tend to either be overly generic (also a cognitive overhead, especially when you have multiple such generic names), or too specific and therefore quickly inaccurate (and even larger cognitive overhead).

Oh, and as for "If it's not that big rename it" - this article is specifically about things that are hard to rename (e.g. public facing APIs or libraries):

> Now, if a name is going to be easily changeable forever, please do make it descriptive.