Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Names should be cute, not descriptive

ntietz.com

Post reply on HN
Print view View original

411–420 of 498 posts

Re: Names should be cute, not descriptive

#411

Post by anchochilis »

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

Re: Names should be cute, not descriptive

#412

Post by avanai »

mrweasel wrote: post #139
PragmaticPulp wrote: post #10

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.

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 clu…

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.

Re: Names should be cute, not descriptive

#413

Post by IshKebab »

feoren wrote: post #355
PragmaticPulp wrote: post #10

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.

> 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 o…

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.

Re: Names should be cute, not descriptive

#414

Post by lamontcg »

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.

Re: Names should be cute, not descriptive

#415

Post by MichaelDickens »

PragmaticPulp wrote: post #10

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.

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.

Re: Names should be cute, not descriptive

#416

Post by allknowingfrog »

anchochilis wrote: post #411

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…

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

Re: Names should be cute, not descriptive

#417

Post by ppqqrr »

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.

Re: Names should be cute, not descriptive

#419

Post by spullara »

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.

Re: Names should be cute, not descriptive

#420

Post by imwillofficial »

mlyle wrote: post #393
throw__away7391 wrote: post #388

Earlier quoted context omitted.

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.

> Why would you shove unrelated functionality into the same service? Because you notice that Broadcast-Service happens to already know some other important stuff about all the enregistered clients. And perhaps answering queries about that or naming ends up becoming its most important job... even though it was originally just a simple broadcast service. Then, later, you end up not even using the broadcast functionalit…

Then change the service name.

“The name doesn’t reflect its function anymore” is not a good case for “let’s name it some random thing”, and certainly not a good case for “let’s arbitrarily give descriptive names for some resources over others”

Post reply on HN