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

471–480 of 498 posts

Re: Names should be cute, not descriptive

#471

Post by nix-zarathustra »

JackFr wrote: post #285
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.

You can have the worst of both worlds. I've worked at three(!) seperate companies which have had projects called 'Hydra' (and the number of people who were ignorant of what the Hydra was, and why it might not have been a great name for a software project never ceased to amaze me.) I like clever, cute names. That is names like Hydra, Spirit, and others which are unrelated to the function, but which are anodyne and gen…

Mozilla was named because the browser was going to be a "Mosaic killer". They made a bug tracker which they named bugzilla. Atlassian made their own bug tracker called Jira, in reference to the japanese transliteration for godzilla, "gojira", which is similar to bugzilla.

Re: Names should be cute, not descriptive

#472

Post by nsonha »

atoav wrote: post #402
nsonha wrote: post #126

Earlier quoted context omitted.

> memorable name is it ever a problem in software engineering, that you can't remember what that component's name is? I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name, and maybe they don't do SEO well on package repositories (why would they, software engineers). So, when I look npm up for that problem, th…

> I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.

No you were clearly arguing for "memorable". Do you argree now that it's a worthless quality for a name? (in software engineering)

Re: Names should be cute, not descriptive

#473

Post by danparsonson »

gilbetron wrote: post #362
danparsonson wrote: post #249

Earlier quoted context omitted.

Exactly! That's why I always advocate giving every monitor in an office its own unique name (mine is Moe!) and every keyboard, chair, desk, etc. Who wants to use those stuffy descriptive generic names?? Obviously trademarks and other product names are more useful if they're unique; Google, Apple, etc. are not components of a system, they're products. It's like getting your car fixed - they don't tell you the Jane and…

So you name your keyboard "character-event-generator-1", your chair "butt-and-back-holder-1" and your desk "four-stick-and-board-to-hold-items"?

Nope - we already have widely understood descriptive nouns for those things. If I walk into an office and someone asks me to bring a chair over, I know instantly what they're talking about. They might need to qualify it - that blue, high-backed chair with the arms, for example - but if they said 'bring Clive over', I'd be stuck until I learned the (fun!) names of the office chairs, and would likely be confused for a long time until I managed to remember who was who, not to mention that there would be no other incentive to learn those names as that information has no value outside the office. This is the point at issue here.

We also have widely understood descriptive nouns in software development - for example if I hand you a class called 'xyz-repository', you probably know instantly that it's a class designed to manage the lifetime of xyz objects that are persisted to and retrieved from a database. If we had an identity service we could choose to call it:

a) login-and-token-management-service, per your example; unnecessarily wordy but obvious b) identity-service c) gatekeeper, which is fanciful but at least slightly descriptive; we'd probably be able to guess its purpose from the name d) dr-octopus, which is lots of fun and completely useless for helping me to remember what it does

Hopefully you can see that b) is the most boring but most widely understandably name; if b) is not an option because we've invented a new thing that doesn't have a descriptive noun, then a) is still the best choice of the remaining three as it tells everyone what it does without requiring any inside knowledge.

It's about cognitive load - some DSLs add value, others just increase the amount of mental effort required to understand the system.

Re: Names should be cute, not descriptive

#474

Post by danparsonson »

jeroenhd wrote: post #118
germanfella wrote: post #55

I made an account on HN because this is the worst post I have ever read here. NO!!!! DON'T USE CUTE NAMES!!! I am currently working with a big company for my apps and it is full of cute names which are the biggest problem for me. To launch an app you have first to integrate the Zaamla-Service into your IDE. Then just patch things up with Pimble, upload the signed HIMA-Package into the Katala and activate after that Z…

Would this be easier if you needed to integrate with user-provider-service, timestamp-conversion-service, image-storage-service (which also stores videos these days, though HEIFF and h.265 has obviously been moved to iOS-image-storage-service so customers can be billed for the special software that requires patents) to upload a signed SecuredApplicationPackage file to InternalExternalSoftwareManager so that it can be…

Yes that would absolutely be easier - I don't understand why this is controversial?

If you have a bunch of services, some of which are relevant, some are not, and domain knowledge is required to understand which to use at which times, then that problem exists independently of their names, as you say. Naming them after Pokemon obviously makes it more difficult to learn which is which; how can it not?

Do you really think that

user-provider-service, timestamp-conversion-service, image-storage-service

is no easier to follow than

bulbasaur, charmander, squirtle

? After ten minutes of 'eevee depends on charizard, which in turn requires mewtwo' I would be utterly lost.

Re: Names should be cute, not descriptive

#475

Post by WuxiFingerHold »

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…

I agree in that the need to refactor large amounts of code because of changes in the marketing product name is insane.

If the devs had just ignored the change the first time (kept the name integrationhub) the separation would have happened naturally.

Re: Names should be cute, not descriptive

#476

Post by AYBABTME »

xeyownt wrote: post #183
AYBABTME wrote: post #148

How about making them descriptively memorable: - shifting-priorities-routing-service - indiscrete-secrets-vault - gdrp-user-immolator - knock-knock-whos-this-authn - canihaz-authz I don't buy the "can't rename services" arguments though. It's also hard to rename variables, modules and stuff. We do it. I'll tell the PM I need to rename this function if they want to know what I'm up to. How often does a service morph s…

The advantage of making cute is that you can also make them small. I would really hate using shifting-priorities-routing-service all over the place, in particular in combination with steady-allocating-routing-service. Between cute/descriptive, long/small, it all depends on how often/where/long these names are used.

You can call it by the cute name in casual speech and still guess what it does by looking at the process/deployment/artifacts name. "I'll deploy knock-knock-whos-this this afternoon" -> `kubectl apply -f knock-knock-whos-this-authn.yml`

Re: Names should be cute, not descriptive

#477

Post by atom_arranger »

fiddlerwoaroof wrote: post #75
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.

I have the opposite problem as a recent new hire: when "cute" project names show up in a conversation, it signals something company-specific I need to learn about. When descriptive project names are used (especially if the projects are using really generic one or two word names like "routing-service"), it is harder to realize that people are talking about an implementation of a concept rather than a well-known concep…

I tend to jump to the opposite conclusion. If a name is cute I assume it’s something open source, named for marketing or SEO. If a name is descriptive I assume it’s probably internal.

Re: Names should be cute, not descriptive

#478

Post by kqr »

Macha wrote: post #366
kqr wrote: post #342

Earlier quoted context omitted.

I think there could be a difference here: you're already familiar with the domain brew operates in. The system I'm speaking of were extensively used and configured by people who had no prior experience with event-driven, branching logic, nor any familiarity with the terms involved. You can still argue it would have been more efficient to teach them that domain first, then teach them this particular system for it. May…

I'm not sure assuming people are familiar with the process of alchohol brewing is any better.

I agree -- that's exactly what I was saying. The target audience of brew is more likely to be familiar with package management than alcohol brewing, so the choice of terminology was poor. On the other hand, the target audience of the system I was discussing is more likely to be familiar with a fantasy-like narrative than an event loop, so the choice of terminology was beneficial.

Re: Names should be cute, not descriptive

#479

Post by ddulaney »

bmitc wrote: post #211
ddulaney wrote: post #205

Earlier quoted context omitted.

Software names and component names can be really hard to change though, especially because those names tend to leak into the public API. When my company got acquired, they rebranded our C++ library, but to this day the old software name persists in the namespace it uses because they weren’t willing to break every customer’s code. The name of the software can become part of the API in lots of ways (URL component, C++…

So why not rename versions to cutesy names then? Function names? Argument names? That way, you never have to rename anything and can just change the behavior.

Sorry for the wall of text. I found your question super valuable for crystallizing my thoughts. TL;DR: Abstract names are good when your scope is poorly defined and hopefully your functions aren't like that. If they are, maybe consider abstract names for them.

The author's argument is that large software components tend to shift in scope over time, so a very concrete name will become incorrect as the scope starts to misalign with the name. A hard-to-change concrete name at that point becomes a misnomer, and it would be better to have had the abstract name from the beginning. I'm resisting the word "cute" because I don't think that's really the core here -- the question is if names should be abstract or concrete, and the abstract names can be whatever aesthetic you want.

Why not use abstract names at smaller scales? I can come up with a couple of reasons:

First, smaller-scale constructs are easier to predict. The project as a whole might go in a ton of different directions and get pressed into service for a ton of different tasks. But my encodeBase64 function will only ever do one thing, and I can predict that pretty reliably, so I can give it a concrete name. I hope to someday find a codebase where every function is like this ;).

Second, smaller-scale constructs often have names that are easier to change. Most functions you write don't end up as part of some API, and the ones that don't can be given specific names with the understanding that it's easy to change them later if you have to. Obviously, this doesn't always apply.

Third, smaller-scale constructs suffer from less scope drift. I find that the pressures to change scopes are generally on the project as a whole, and a large part of extending a system well is to adapt the project as a whole to those pressures while protecting each individual component from them as much as possible. If you can do this well, each small component gets to be more stable than the project as a whole and can support a more concrete name.

Finally, maybe you should sometimes! Maybe you have a function that has had massive scope drift such that the name no longer applies. It started life as updateCustomerBalance, but now it's reaching into the supplier database too, and appending to a financial report, and hitting some backend servers at one of your vendors. The name is now actually misleading. (Ideally we'd refactor, but this article is just about naming.) It might be better with a highly abstract name -- if you don't like the cute route, something like executeBusinessLogic is abstract in the same way. It might be more honest than the specific-but-wrong name.

Re: Names should be cute, not descriptive

#480

Post by atoav »

nsonha wrote: post #472
atoav wrote: post #402

Earlier quoted context omitted.

> I find it more of the problem when people make a good library that solves a problem with a predictable name, but then they give their library some other cute name This is why I said Boaty McBoatface. You look for Boats? It has "boat" literally two times in it's name.

No you were clearly arguing for "memorable". Do you argree now that it's a worthless quality for a name? (in software engineering)

I disagree that it is worthless.

What I agree with is that it is not strictly necessary, but that is a label that you can stick on a lot of things. Things that make our lives easier. Memorability of names is not a necessity in software engineering, just as is descriptiveness, but it certainly does not hurt.

Post reply on HN