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

191–200 of 498 posts

Re: Names should be cute, not descriptive

#191

Post by bmitc »

superb-owl wrote: post #185
bmitc wrote: post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

> Trouble is, names are hard to change. > No they’re not. People just aren’t determined or organized. This is very untrue. Many moons ago my company changed its name, and we still have the old name lingering around in stupid places. There are e.g. several third-party services which simply won't let us change the name and carry our data forward, or where proper migration would take eng-months. I guess you could say we…

We're talking about software service and component names. Not names in general or company names.

Re: Names should be cute, not descriptive

#193

Post by btbuildem »

This is one of the hardest problems in software development, and with good reason. Naming things is how we get a handle on them, how we mark our understanding of them. It's a pivotal issue, in how it attaches our brain-maps to the problems we tackle.

How many times, as a developer, have you paused and pondered what to name a new entity? I often find the difficulty of naming a thing is directly proportional to my depth of comprehension of that thing, what it does, and the context it lives in.

With that in mind, I see naming-things-for-what-they-are as one winning strategy.

Quoting from OP:

> The problem comes in when there's a mismatch between responsibilities and names. Names are a way of expressing identity, while responsibilities are ephemeral: Your friend Sam is still Sam, even if Sam gets new responsibilities and sheds old ones.

I find this a bit misleading, since Sam is a person with agency and a unique personality, and the things we name are, well, things, with specific purposes and raisons-d'etre.

But! At the same time, OP identifies a key characteristic of things-that-persist -- scope creeps, features are added, responsibilities evolve. Naming a server "Sysyphus" may seem cheeky at first, but I'd argue that it's a better name than "Load Processing Server 2". We tend to antropomorphize things, that's one, but also - things happen over time, notable events, that create a timeline of stories which in turn build up into the coherent base of knowledge / familiarity / wisdom that ties teams together. Using "humanized" or "personalized" names pays off here, they help to glue these stories together and contribute to the institutional memory that builds up over time.

In the end, I think both approaches are valid and have their place, we just have to use our judgement as to when to use which.

Re: Names should be cute, not descriptive

#194

Post by MayeulC »

vvillena wrote: post #137
mattlondon wrote: post #129

No no no no no. Please never ever do this. From experience, this is thew worst possible decision to make in anything apart from the smallest of organisations (i.e. where production is small enough that all the engineers know (like, really know inside-out and have it all in their head - not just "aware of")), at which point you don't have much to worry about when it comes to renaming something. Please, put yourself in…

As per the article: The problem is that descriptive names don't stay that way. Descriptive names turn into misleading names as the things they refer to change over time. And while code can be refactored, it's very hard to refactor a service name, and almost impossible to refactor it away from people's minds.

Well, if you change the role of a named thing, change the name too. The role change is probably breaking many assumptions already.

You can also keep the old name around as a stub to talk to the new one, if needed (like during a transition period where it becomes deprecated).

Re: Names should be cute, not descriptive

#195

Post by thenerdhead »

I work somewhere where naming is notoriously bad both cute and descriptive. If I could wave a magic wand about naming, I would wish that people put less time into thinking about naming. You get better names that way.

A simple exercise in improv could even be applied. What's the first thing that comes to the top of your mind when you think of "X"? If majority of people say the same thing, you run with it because that's the most obvious one. Choose the obvious one.

Re: Names should be cute, not descriptive

#196

Post by hawski »

thenerdhead wrote: post #195

I work somewhere where naming is notoriously bad both cute and descriptive. If I could wave a magic wand about naming, I would wish that people put less time into thinking about naming. You get better names that way. A simple exercise in improv could even be applied. What's the first thing that comes to the top of your mind when you think of "X"? If majority of people say the same thing, you run with it because that'…

I'm afraid it would be tmp and tmp2.

Re: Names should be cute, not descriptive

#197

Post by GuB-42 »

bmitc wrote: post #128

I could not disagree more. > Trouble is, names are hard to change. No they’re not. People just aren’t determined or organized. > It's impossible to predict with certainty how your software's requirements will evolve over time. You don’t need to predict it. You evolve things as needed, including names of components of the system. The idea that you need to pick a generic name because you don’t want to specify exactly w…

> No they’re not. People just aren’t determined or organized.

You just provided your own counterargument. People naturally aren't determined or organized, that's why names are hard to change.

You can't change human nature, you can only work around it, and cute names are a solution for that. Cute names work even if people are disorganized, and they are. Furthermore, cute name, rather than purely generic or descriptive names evoke emotions, making them more memorable, another human thing.

Re: Names should be cute, not descriptive

#198

Post by zelphirkalt »

The purpose of naming things is to convey their meaning and character. By giving a non-descriptive name, one loses that potential. Please do not use cute names, unless there is really no good name to pick (like ad-hoc created docker container names, when --name is not specified). Give me information through means of naming things properly.

Re: Names should be cute, not descriptive

#199

Post by Tangurena2 »

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…

I think the "can't rename it" applies to APIs. Some of the PDF functions have COS as part of their name. The original name of Acrobat was Carousel. COS stands for Carousel Object System. The first version of Acrobat was released in 1993.

Re: Names should be cute, not descriptive

#200

Post by tauwauwau »

I think we are mixing two different scopes in the the discussion here. If you are naming a company or a product that will be offered to clients, name it something unique that'll appear in searches. However, if you're writing a piece of software that's not going to go outside the company, having descriptive name is the way to go.

You can even name your products with generic descriptive names, if your company's name is unique enough, then that'll act as a namespace for product with generic names. Think of packages in Java, C#, we don't debate about that we have to use a cute name for a X.java or X.CS, because that problem has already been solved by namespaces.

Product name Excel and Office works for Microsoft because that "Microsoft" acts as namespace and "Microsoft Office" and "Microsoft Excel" are unique enough to be fully qualified names.

The ntietz entry is talking about using cute names for internal services, which is very bad idea. Please enjoy https://www.youtube.com/watch?v=y8OnoxKotPQ

Post reply on HN