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

431–440 of 498 posts

Re: Names should be cute, not descriptive

#431

Post by banku_brougham »

wvenable wrote: post #395
throw__away7391 wrote: post #374

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, "becau…

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…

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.

Re: Names should be cute, not descriptive

#432

Post by banku_brougham »

rhacker wrote: post #329

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…

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

Re: Names should be cute, not descriptive

#433

Post by surement »

Sholmesy wrote: post #113

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 easier to associate with "Ingest, Processing, & Storage of Thing" than ? EDIT: On closer inspection, I think this is intentional HN rage bait.

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

do flag stories like this

Re: Names should be cute, not descriptive

#434

Post by AtlasBarfed »

erikpukinskis wrote: post #348

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…

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

Re: Names should be cute, not descriptive

#435

Post by banku_brougham »

jcampbell1 wrote: post #375
wruza wrote: post #364

Earlier quoted context omitted.

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

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

as long as they were ubiquitous and containers I have no objection.

Re: Names should be cute, not descriptive

#436

Post by szundi »

banku_brougham wrote: post #431
wvenable wrote: post #395

Earlier quoted context omitted.

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…

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.

If you plan to exit in 2 years and you don’t give a sh*t after that, sounds like a plan!

Re: Names should be cute, not descriptive

#438

Post by mlyle »

imwillofficial wrote: post #420
mlyle wrote: post #393

Earlier quoted context omitted.

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

It's very difficult to change service names, given that you have a large population of people conditioned to say the name and lots of documentation artifacts, other code, etc.

"Broadcast message service" is, as the author points out, way too generic and also too long to be used freely. "Scattershot" rolls off the tongue and won't be completely wrong if functionality changes. And hopefully we have a small enough quorum of services that we don't drown in jargon.

Re: Names should be cute, not descriptive

#439

Post by wvenable »

banku_brougham wrote: post #431
wvenable wrote: post #395

Earlier quoted context omitted.

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…

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.

That's the trade off. You have to decide whether or not it's worth it. But if you never do it, then you end up a with a system where nothing means what it says and that's awful.

I feel the best time to rename something is as early in the development process as possible. Because the longer something is wrong the more entrenched it becomes.

Re: Names should be cute, not descriptive

#440

Post by jakelazaroff »

throw__away7391 wrote: post #421
jakelazaroff wrote: post #394

Earlier quoted context omitted.

> It sounds like your deployment and provisioning infrastructure is sub-par. If you want to add supporting details to that — like, any at all — then we can have a discussion. The rest of your comment doesn't actually relate to anything I said.

If you need to choose a random name up front because you can't predict what the service might be doing someday, possibly you have a poor architecture--services should follow scaling and data boundaries, both of which lock you into a specific (namable) scope, or if we are more charitable to you and blame devops instead it takes too much effort to deploy new services, there too many manual steps involved, or you're doi…

Here's where you lose me:

> You say these are easy to change, but when your infrastructure is set up correctly services are also easy to change, it is all just code.

Unless you have extremely simple infrastructure, it's very much not "all just code": it's programs that are running on different machines that don't intrinsically know about each other.

Then it becomes a coordination problem. For example, if service B calls service A and you want to change the hostname of service A, you need to first make sure that service A will respond to the new hostname, and then that your discovery layer knows about that change before service B — and also that it still handles the old name correctly until service B has been updated.

"Oh, but I have all my infrastructure in [Terraform/Cloudformation/Pulumi/etc], that's not a problem for me." First of all, there are a ton of reasons things might slip through the cracks. Maybe you're migrating from one system to another, or maybe some dependency doesn't have great support, etc. But second of all, infrastructure is stateful and things can go wrong. If your change fails halfway through for some reason, and only some pieces are aware of the new name, are you sure your system is consistent?

Code, on the other hand, is just code — changes are atomic and self-contained. If I change a function name, I know that everything that could possibly use that function is contained within my codebase. When I deploy, it's either using the new name or not — and it doesn't matter if half of my servers have different names for the function, because they don't interfere with each other.

The one exception to this is public APIs, which are difficult to change without breaking downstream consumers. But consumers can always choose not to upgrade their version of the library. And when they can't — when it's a proxy for an external dependency, like a web service — the issue isn't the name in the code, but the name in the infrastructure.

Post reply on HN