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

451–460 of 498 posts

Re: Names should be cute, not descriptive

#451

Post by seniortaco »

liotier wrote: post #360
seniortaco wrote: post #346

Earlier quoted context omitted.

Why would anyone still build it manually? Tokidoki automates all of that, and all you have to do configure your .toki bundles after you've installed the right SpaghettiWare layer for your architecture and connect it with either Tutti or Frutti. Easy peasy lemon squeezy! Oh that reminds me you do need Squeezy running in the background.

Uh ? Aren't your .toki bundles autogenerated from picks in the CherryOrchard directory ? Don't touch them - let the NoodleBlossom pipeline trellis abstract that for you !

Oh goodness, well I was just on a two week vacation and it looks like NoodleBlossom was created last week, I feel like some kind of cave person over here! Trellis pipelines are slick!

Re: Names should be cute, not descriptive

#452

Post by throw__away7391 »

ubercow13 wrote: post #425
throw__away7391 wrote: post #421

Earlier quoted context omitted.

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…

It's not always possible to know upfront the perfect architecture of your whole system. Not every business domain is as trivial as 'delivery notification'.

If you change "not always" to "almost never", I'd agree with you. I still think you can give your services descriptive names. Even non-trivial domains can have a name.

Anyone building a monolithic application is using packages or sub-modules to organize their code. While basically all monolithic applications have some kind of product or code name, I have never once seen anyone give a sub-module a weird cute name. But deploy that same code into a container and suddenly people want to start calling it "Skywalker" or "Cthulhu".

If you are using Domain Driven Design (or something similar, hopefully you're using some kind of methodology), naming the domain is one of the very first steps. You should be able to come up with a name for a service domain that is descriptive enough such that a major change to the name would also mean it was a different service.

What I am seeing is all the pro-cute names arguments against this seems to be describing a scenario where you're just sort of randomly adding code to services out of convenience. This is very much putting the cart before the horse and I don't really know what else to say beside that if you're doing that I think having cute names is probably the least of your problems, particularly when you're talking about long term maintenance of this software. These names do eventually have to be described to someone, and if you can give a coherent description of what the "Birdman" service does, you should be able to give it a good name.

First and foremost, services should own their own data, therefore it necessarily follows that service boundaries will follow data/domain boundaries. The second most important consideration for service boundaries is scaling points, which in turn directs service boundaries to follow specific interactions. I almost never break up services unless they cross one of these two lines, and taken together they give a scope of data and activity for any service that is enough to give it a descriptive name.

Re: Names should be cute, not descriptive

#453

Post by Damogran6 »

DaedPsyker wrote: post #147
eps wrote: post #103

Earlier quoted context omitted.

Even HN frontpage sometimes be "How I use Kawai Wasabi on Yakotori under Sashimi" and there'd be 100 comments, all of them serious. Makes one feel excluded.

Tech naming has become a pet peeve of mine. Too many common nouns are being used. 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.

Verbnouns - ActiveCrab, StormTorch, Plinth, Bonobo, ElasticStack, FrodoBlight

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)

Re: Names should be cute, not descriptive

#454

Post by janef0421 »

I think this is probably two far to one side. It is true that naming something purely descriptively may lead to misconceptions as its function evolves, but a "cute" name doesn't do anything to inform someone what it is. I would argue that best name has some semantic connection to the function, but is also somewhat abstracted; This allows it to be informative while accommodating evolution.

Re: Names should be cute, not descriptive

#455

Post by ram_rar »

Hard disagree. Especially for backend/infra or any cross team usage. One of my previous company widely popular for crunching logs had starwars esque names for various services and Kubernetes infra. It was a terrible decision, since it lead to another layer of abstraction to know what those meant in the context, also when employees churn, reorgs happen, a lot of this info gets lost into oblivion.

Re: Names should be cute, not descriptive

#456

Post by pwinnski »

If the reason for this is that it's hard to change names, then the solution is to make it easier to change names, not to use stupid names. A given service should run on hardware/VMs that are named related to that service, and if the service goes offline, so does that hardware or those VMs, to be repurposed (and renamed) into something else.

Anything else leads to madness, or starts from madness.

Re: Names should be cute, not descriptive

#457

Post by kerkeslager »

feoren wrote: post #387
kerkeslager wrote: post #380

Earlier quoted context omitted.

There are so many straw man arguments in this post it's hard to play them apart. > Early chemists gave cutesy names to chemicals, like "vitriol", "salt", and "cholesterol". Today we know the proper descriptive names for these substances, of course. That's not what happened, and nobody is saying that the chemical serialization is the "correct" name. The reality is that originally we didn't know the internal structure…

> The naming grew as our understanding of the function grew. Yes! That's exactly it! You have accidentally made my point exactly. The name grows as the understanding of the function grows. And your understanding of what a given service or application should be doing is always growing and changing over time. So if your name is an encoding of the function, it will constantly change and grow, until it's as ugly and usel…

> > The naming grew as our understanding of the function grew.

> That's exactly it! You have accidentally made my point exactly.

No, you just ignored the point I made later about it being contextual.

> > Nutritionists don't necessarily need to know that Vitamin C is an acid, and they certainly don't need to know the exact chemical structure of cholesterol.

> Yes! That's exactly it! Your CRM program doesn't need to know that your spell-checking service is also a translation service, and your international logistic program doesn't need to know that your translation service is also a spell-checking service.

1. ...but your CRM service does need to know that your spell-checking service is a spell-checking service, and your international logistic program does need to know that your translation service is a translation service.

2. Your spell checking service shouldn't also be a translation service, and your translation service shouldn't also be a spell checking service. If you violate single responsibility principle, then "Play stupid games, win stupid prizes" applies. Naming is the least of your problems in this situation.

> Absolutely spot on. I spent about 30 seconds coming up with "Wordsmith". It does something with words.

Well, maybe until you're better at it, spend more time.

> I agree the word should not be completely divorced from its use.

Then you disagree with the OP.

> We all treat "hiding details" important in code. If every part of my code depends on every other part of my code, then one change will mean 100 changes.

Again, play stupid games, win stupid prizes. If every part of your code depends on every other part of your code, don't do that.

> The answer isn't "well, just make sure those 100 changes are super fast, and ignore the constant thrashing in your git history". The answer is standard programming practice of sharing only the details that are relevant to others.

Surely what the thing you're calling does is relevant to you?

Re: Names should be cute, not descriptive

#458

Post by tastysandwich »

Imagine starting at a new company and you view a big diagram of all the services. "Flipper connects to klunker, which has a database called plomb. There's an arrow going from gonky all the way down to zippydoo, which generates a report that gets handled by fogle. And all this is orchestrated by butt".

I also like descriptive names because they help me fend off service bloat. "Sorry, it doesn't make sense to add bespoke client integration to report-generator. But we can make a new service which takes those reports and sends them to ABC Corp if you want."

Re: Names should be cute, not descriptive

#459

Post by spfzero »

aaronbrethorst wrote: post #403
dlivingston wrote: post #397

Earlier quoted context omitted.

Related-ish, but Apple's macOS APIs are peppered with references to NeXTSTEP. I find this charming. For example, NSView (spelled out - NextStepView). https://developer.apple.com/documentation/appkit/nsview

NeXTStep used "NX" prefixes, and its successor, OpenStep, used the prefix "NS". "NX" stood for "NeXT", "NS" stood for "NeXT and Sun". https://news.ycombinator.com/item?id=15973609

IIRC the NS prefix was in use long before there were any dealings with Sun. There was software development going on at NeXT before they had the name for the OS ("NeXTStep"). So, NX for NeXT, NS for NeXTStep.

Re: Names should be cute, not descriptive

#460

Post by layer8 »

banku_brougham wrote: post #432
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.

I don’t think it was supposed to be, given the introductory “while”.
Post reply on HN