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

291–300 of 498 posts

Re: Names should be cute, not descriptive

#291

Post by noveltyaccount »

kqr wrote: post #49

TFA is based on a false dichotomy. You can have both. At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system. In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locat…

This is a great anecdote. I'm firmly on the "call things what they are" side of this debate, but this example shows a thorough domain design that was cleverly shifted to a narrative format. Impressive.

Re: Names should be cute, not descriptive

#292

Post by grahar64 »

xcambar wrote: post #163

A company I have visited had, for some obscure reason, decided that teams should have their own fun/memorable names. Almost 2 years after implementation, every new hire's first comment was: "it's impossible to navigate the org with those names, we have no idea of what each team is doing". I could live with funny+descriptive, but for all that is good, funny only just does not work.

Yes, and we should change an entire companies culture to make a new hire onboard slightly faster /s

Re: Names should be cute, not descriptive

#294

Post by grahar64 »

salawat wrote: post #286
toomanyrichies wrote: post #253

Earlier quoted context omitted.

> descriptive names might eventually become non-descriptive It's worse than being non-descriptive- it's that they become misleading . "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing . This, in turn, means developers can no longer trust that a descriptive name is accurate. It plants a seed of doubt in a developer's mind about other names. It tells them that, here at WidgetCorp…

>It's worse than being non-descriptive- it's that they become misleading. "Cute" names don't tell you anything. Formerly descriptive names tell you the wrong thing. My God... You don't mean to tell me you actually object to having to read code and figuring out what it does in the grand scheme of things? I swear, everyone wants to be a writer, but no one wants to read and understand.

You shouldn’t have to read code to understand architecture. But I have had so many conversations like “this is the Auth-service, it also loadbalances and stores a bunch of state, oh and doesn’t do Auth anymore”. Then the name becomes actively harmful to understanding the system.

Re: Names should be cute, not descriptive

#295

Post by grahar64 »

kqr wrote: post #49

TFA is based on a false dichotomy. You can have both. At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system. In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locat…

Great idea!

Re: Names should be cute, not descriptive

#296

Post by williamcotton »

pfix wrote: post #243
williamcotton wrote: post #234

Earlier quoted context omitted.

The problem with using a brand name in code is that the audience for the brand name is external to the company and subject to change due to conditions in the market. The problem with descriptive names arises when it becomes hard to distinguish between components named “AdServer, “AdRendererServer”, “AdStorageServer”. It’s liking naming a WWII bomber “Fuddy Duffy” and painting Elmer Fudd on the side. It’s a lot easier…

Isn't that why namespaces were invented? You put those in the namespace `AdServer: { Server, Renderer, Storage }`

Sure, but what if the AdRendererServer is written in Python and the AdServer is a Rails app? These tend to get turned into acronyms like ARS and AS, and then “ars” and “as”. So a meaningless grunt or an evocative, memorable word?

Re: Names should be cute, not descriptive

#297

Post by devnullbrain »

stared wrote: post #293

Let's go further: Function (and class) names should be cute, not descriptive. It is impossible to predict how these evolve and change their names.

The mirror to this argument is that company names should also be descriptive. Goodbye Amazon, hello OnlineBookStore.

Re: Names should be cute, not descriptive

#298

Post by hooverd »

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…

What's not to understand about the account-provider-router-service? It's key to the business-data-sync service. We're working on a new account-provider-aggregator to replace it though.

Re: Names should be cute, not descriptive

#299

Post by devnullbrain »

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.

This would actually make the situation in TFA worse. The new hires would assume that foober foos when actually it's being used to bar. Either way there's a need to memorise - without cute names you gain the additional problem of close but dangerously wrong assumptions.

Reading documentation is not a bad expectation of a developer.

Re: Names should be cute, not descriptive

#300

Post by bumby »

GuB-42 wrote: post #197
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…

>You can't change human nature, you can only work around it

You can create systems that provide the guardrails and incentives to modify human behavior though.

The root of much of this discussion is communication, which is a near-ubiquitous problem in relatively large organizations. Communication, in this instance, is that people want to have a clue about what something does.

The authors point is that as code changes, the names may no longer communicate what that code does. Unfortunately, their suggestion to make cutesy names does nothing to fix the communication issue. We're still left with poor communication about what the thing does. It's a veiled attempted to pretend like they're solving the problem of communication, but it's just a disguise that leaves the same problem at the end of the day.

At least with descriptive names, I can have some clue as to what the code used to do, and maybe glean from that why it is the way it is now.

Post reply on HN