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

211–220 of 498 posts

Re: Names should be cute, not descriptive

#211

Post by bmitc »

ddulaney wrote: post #205
bmitc wrote: post #191

Earlier quoted context omitted.

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

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.

Re: Names should be cute, not descriptive

#212

Post by lo_zamoyski »

moffkalast wrote: post #151
alexvoda wrote: post #140

Earlier quoted context omitted.

Kawai Wasabi is incompatible with Yakotori. It is a known choice by the lead developer. When using Yakotori you should use Tare instead.

Yeah but Tare doesn't scale as well as Marmot, plus it has Tenimoshi support.

Would you please pass the jelly?

Re: Names should be cute, not descriptive

#213

Post by Drakim »

bryanrasmussen wrote: post #116
doctor_eval wrote: post #46

Earlier quoted context omitted.

But that's my point. You start writing a new policy engine, and you think the name is obviously descriptive. But in 12 months time, it's not so obvious any more, and also you probably have 3 different policy engines for different use cases.

Ok but the image-optimization-engine that Carl wrote still seems descriptive to me those same 12 months later. So I think policy-engine might have seemed descriptive but it just wasn't whereas image-optimization-engine was descriptive.

At least until it also starts converting gifs to webm, and soon other formats like mp4, and since it's being used for video it needs subtitle support in various languages.

Re: Names should be cute, not descriptive

#215

Post by bmitc »

superb-owl wrote: post #207
bmitc wrote: post #191

Earlier quoted context omitted.

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

It's the same principle IMO. The name gets repeated in so many places if it's important. Documentation, code, URLs, databases--even just finding all the places you need to change it involves a ton of work.

See my other comment in another reply, but are you suggesting that it's better for something to keep the same name while also changing its behavior and purpose? It doesn't make any sense.

Re: Names should be cute, not descriptive

#216

Post by gwhl »

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 describes absolutely nothing to me. It just confuses and excludes me. Then if and when I understand what it means I then have constantly translate mentally between the cute-yet-infuriating names and their actual meaning in the context.

Re: Names should be cute, not descriptive

#217

Post by discreteevent »

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

Yes you can. When a person becomes a civil engineer they are trained to change their nature so that when they design a bridge they do it in a way that meets all the standards with full documentation rather than the way they would sloppily design their dogshed at home.

Re: Names should be cute, not descriptive

#218

Post by civilized »

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…

> You end up with the situation of not being able to say “Startrooper does ” because it doesn’t just do .

And this leads to all the dysfunctions software engineers are supposed to care about protecting against. If a system has no high-level invariants, it is an organically evolved hairball that only a small number of Gurus, typically the people who oversaw the entire multi-year evolution of the hairball, understand or care to understand. This sets you up perfectly for endless Lava Anti-Pattern hell: only a Guru can change the system. For everyone else, the system can never be changed, only added to.

That said, point taken from the other comments saying how names can be hard to change due to external constraints. Maybe the name matters less than the discipline to make sure that "Startrooper does X and only X". Internal documentation should attempt to thoughtfully name or concisely describe the functionality of something, and if it's not possible to do so, that suggests that the system does not follow modularity best practices.

Re: Names should be cute, not descriptive

#219

Post by whoisthemachine »

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…

I too have worked in code bases that have included one or two company name changes in them, and it can really add unnecessary noise to the source. So I think this is actually a counter-argument for using "cutesy" names - swap "cutesy" with "branded" names, and you may see what I mean. This is a basic thing I learned early on and teach others - do your best to not include the name of a product in your codebase, rather focus on the function when trying to name something. It will do you no good if something is called `MyCompanyCart` when it instead could have just been called `Cart`. Most of all, don't include the name of the company in the codebase, especially as variable names, and double especially in data definitions.

Re: Names should be cute, not descriptive

#220

Post by tialaramex »

michaelmior wrote: post #142
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. I think this point from the article gets to the harder part. > Once you've said a name, it starts to stick in people's heads, and it slips beyond your control. Other people use the name in conversation and it ripples out through the organization. Technical modifications to change a name are one thing. Once people a…

Right, there are cases at work where users are like "Foo doesn't work" and you have no idea what Foo is, and turns out the users call it Foo because that was the name of an in-house service 15 years ago which did roughly the same thing, then we switched to Cloud Bar, and actually a few years ago Cloud Bar went on Our Incredible Journey https://ourincrediblejourney.tumblr.com/ so we built a new in-house service Baz, which mimics most of what Cloud Bar did, yet the users still call it Foo even if they weren't here 15 years ago, that's what the person who taught them called it. You need to investigate a problem in Baz, even though the user said Foo, if you like you can tell them it's Baz as well, but like when teenagers correct their parents about teen slang it's not likely to have much real effect.

And you might say, "Descriptive names would fix that". No they wouldn't. The user thinks Foo is a Wibbler Manager, if you called it "Wibbler Manager" they'd agree that's descriptive - but actually managing wibblers is trivial, its main purpose is to stop them from mis-managing the wibblers by providing detailed Doop-de-doop so they stop messing about with the wibblers when they're perfectly fine. Which means the Cloud product it got replaced by isn't really "managing wibblers" at all, it's a Doop-de-doop viewer. Except whoops, nobody makes a cloud Doop-de-doop viewer, so it's actually a Thingy viewer, and there's a shim turning Doop-de-doop into Thingy. When this gets in-housed again, chances are the in-house replacement still just handles Thingy. So in terms of description the user thinks their problem is with the Wibbler Manager, but it's actually the Thingy Viewer... we're no better off, you still need somebody to tell you what the hell the users are talking about.

Names are what people call things, it is rude to call people by a name they don't like. But inanimate objects don't have feelings, so you should just call them whatever you want. Emperor Norton Bridge is a better name than "Bay Bridge".

Post reply on HN