Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

251–260 of 339 posts

Re: Software component names should be whimsical and cryptic

#251

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

You chose childish names one'd presumably be embarrassed to say to an outsider, but... Assuming you can stomach saying the project's name out loud, what's to lose?

What method would you propose teams used to name a project, in which "fun" names are discouraged?

Re: Software component names should be whimsical and cryptic

#252
post #123
post #108

The author seems to be talking about names for two totally different things, lumping them under the term "component." Whimsical project name? No problem. Whimsical type name within a project? Really bad idea. Whimsical variable name? Don't even think about it. The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and varia…

Reminds me of the classic "how to write unmaintainable code": https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un... Especially this bit: Bedazzling Names Choose variable names with irrelevant emotional connotation. e.g.: marypoppins = (superman + starship) / god; This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to thin…

I did this in an infosec class in undergrad 15 years ago, inspired by exactly this essay. The first part of the project was to write a program that password protected a file, and the second part was to try and break each other's programs, with full source code access. I think it helped discourage people from trying to deal with mine as opposed to other people's. (Also, several people correctly guessed that it was mine despite the code being nominally anonymous...)

Re: Software component names should be whimsical and cryptic

#253

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

Klomgan? This argument is a straw man because those names are all ridiculous and defeat the purpose of the naming strategy. If a real organization adopted the naming strategy described by this article, reason would quickly become a part of it, and all those names would therefore be disqualified. Nobody knows what a Klomgan is and it's a made-up word that's difficult to pronounce. Why would anyone suggest it? How about marshmallow, lemonade, candlestick, or zephyr? Those are some simple dictionary names that are easy to say and aren't overly distracting or offensive.

Maybe "whimsical" isn't an accurate moniker. Generic or Common is how I would label the naming strategy described by this article. "Whimsical" is just asking for trouble and opens you up to overtly stupid names like "Chumbawumba."

Re: Software component names should be whimsical and cryptic

#254
post #106

Inside this essay giving horrible advice, is more horrible advice: > Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those. People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actuall…

Sure but what to do if all the good names for doing the thing the thing is doing are taken ?

Qualify the duplicate name with why you have a duplicate.

Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain)

You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.

Re: Software component names should be whimsical and cryptic

#255

Earlier quoted context omitted.

I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently. The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and ju…

It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more li…

I'm saying it's not just webservice monoculture. It predates the web. Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git?

If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.

Re: Software component names should be whimsical and cryptic

#256
post #47

I do like the Intel code names like Tiger Lake, Light Peak and Ivy Ridge. They evoke some kind of combination of Manhattan project megaproject and just-charted territory.

Those are release names, like Sierra and Mojave for MacOS. Different. There, you can sort of go nuts. The product name is still, well, "processor".

Product family is Core iX, Xeon, Atom, Pentium X etc. Intel® Core™ i9-9900K Processor is a product name.

Lucky you generally only care about release names within a single product because thinking which one is Jasper Lake and which one is Alder Lake is not something I want to do.

Even those product names are not excellent either: Intel introduced i9 which is essentially what i7 used to be and used to justify higher price - look i7 is the same price, but it's the brand new i9, that is totally wouldn't be called i7 5 years ago, that cost more.

Re: Software component names should be whimsical and cryptic

#257
Think of the new people you hire!

It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.

What is easier to understand at first glance?

Picard stopped responding to Luke. Bilbo is also down!

or

PaymentService stopped responding to UserService. Database-XYZ is down!

It might not be exciting but the cognitive load is much lower.

Re: Software component names should be whimsical and cryptic

#258
post #253

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

Klomgan? This argument is a straw man because those names are all ridiculous and defeat the purpose of the naming strategy. If a real organization adopted the naming strategy described by this article, reason would quickly become a part of it, and all those names would therefore be disqualified. Nobody knows what a Klomgan is and it's a made-up word that's difficult to pronounce. Why would anyone suggest it? How abou…

I think Chumbawumba would be a good name. Just nickname it Chubby or Chewy. It's not significantly worse than Kubernetes.

Re: Software component names should be whimsical and cryptic

#259
Strong "Death of Perosnality"[1] vibes here! That was about ux, this is more about dx. In that thread I advocated pretty heavily for apps not being special[2], for their best service usually being to get out of the way, to be slim & light, focused less on initial charm & more on enduring usability.

I think most of that applies here. The whimsy & fun is cute at first, but it's rarely long term magic. For new teams & outsiders, it's a pain. I've had to work eith a sync engine where there's 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There's probably something cute & creative & whimsical to the authors, but as someone trying to use the thing, it's merciless & oppressive, a huge turn off.

[1] https://tdarb.org/blog/death-of-personality.html https://news.ycombinator.com/item?id=32777411 (79pts, 3d agi, 63 comments)

[1] https://news.ycombinator.com/item?id=32791861

Re: Software component names should be whimsical and cryptic

#260

Earlier quoted context omitted.

The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky. In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge pr…

On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service. A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a c…

Asking the author to provide more context on what domain(s) their blog post is meant to apply to is a reasonable critique.

However, consider whether your original post made that critique clear, or if it got lost amidst the other ... stuff. The first two lines, in particular, will immediately put some readers (myself included) on the defensive. Describing somebody's work as "some web service bs" is a bad start. And if your point had nothing to do with the "hardness" of the problems, only that those particular problems are most relevant to building web services, why not just say that? Instead of the "...somebody who works on some web service bs assumes that that's as hard as the world gets," bit.

Post reply on HN