Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

Post reply on HN
Print view View original

81–90 of 339 posts

Re: Software component names should be whimsical and cryptic

#81

Post by etothepii »

ttiurani wrote: post #59

> See, the scope and purpose of something changes faster than its name can. There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.…

Aim is the problem here. Many projects are built and maintained by people who have a use case.

It may well fit that use case to add one extra feature to the library rather than creating a new library.

I suspect that many of the examples provided (such as the Django project) evolved over time. It can also often be the case that once an implementation is done it becomes obvious that it actually does something very different to what you originally set out to do.

Re: Software component names should be whimsical and cryptic

#82

Post by motohagiography »

I'm on the other side of this, as the author is advocating for using code words to compartmentalize infrastructure, which I think creates absurd bureaucratization and incentivises information hoarding, gatekeeping, and a bunch of other organizational antipatterns.

Business owners and product managers tolerate the whimsy when systems work, but then suddenly when you can't make a feature commitment to a customer on whose relationship your business growth depends - because of the tech debt you accumulated by not priortizing UnicornPoo in your engineering roadmap, you realize your engineering team has essentially betrayed your organization so that they could be lazy and focus on science projects, and the code names were to obfuscate their commitments, and as an expression of spite and contempt for the people they took money from. Whimsy is cute initially, but it quickly becomes uncanny, and even repulsive to see adults acting careless. Cuteness is how children bargain with nature, and in a corporate environment that is about the livelihoods of adults, it is a liability.

Re: Software component names should be whimsical and cryptic

#83

Post by xiphias2 »

saalweachter wrote: post #77
xiphias2 wrote: post #64

Earlier quoted context omitted.

The EE transformer is just as descriptive than the ML transformer. Your complaint is similar to cryptography conference attendants hating the word ,,crypto'' to change from cryptography to cryptocurrency, but that's just the natural evolution of language with technology (not mentioning that the original meaning of the Greek word is hidden/secret).

Does naming a public ledger 'hidden/secret' really make sense?

Of course no, the new naming of crypto comes from cryptocurrency, which comes from currency based on cryptography.

It's not the first time something like this happened, the only difference is that in the past languages evolved similarly in hundreds of years, now a new word can pop up in a day (but most new words get global in just a few years).

Re: Software component names should be whimsical and cryptic

#84

Post by phdelightful »

If you want to see this line of thinking taken a bit too far, check out the list of Trilinos packages on github: https://github.com/trilinos/Trilinos/tree/master/packages

There's ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer / outsider.

(Trilinos is a set of scientific / engineering libraries for HPC)

Re: Software component names should be whimsical and cryptic

#85

Post by wzdd »

MrSqueezles wrote: post #24
xupybd wrote: post #6

This is terrible advice. Cryptic names are horrible. It's a layer of cognitive overhead that no one needs. Yes if it gets so big that it's out grown it's original purpose that's a problem. But if it's really big people know what it is because it's big. If it's not that big rename it!

Yes. The advice is contextual. If you're making a public web framework, probably don't call it Web Framework. If you work at a company and you're writing the one and only hotel booking service, do call it Hotels instead of forcing your coworkers to memorize yet another cute name.

I can easily imagine the conversation after everyone has started using Hotels to book meeting rooms as well, so I think this is an argument for the other side. :)

Re: Software component names should be whimsical and cryptic

#86

Post by dools »

I don’t think you need to go full startup when naming stuff, but you also don’t have to go full bureaucrat either.

I once created a PHP framework called RocketSled because it was “the fastest thing on rails” and that gave rise to somewhat whimsical but also descriptive names on the same theme:

RocketPack: package manager

DataBank: caching auto loader

Murphy: automated testing

Each of those modules is named quite specifically but that’s because they do one thing.

I created an ORM tool called PluSQL, because it’s not an ActiveRecord style ORM but adds a bit on top of straight SQL statements. General enough that if I want to enhance the functionality beyond ORM I can, but also pretty easy to remember what it does from the name.

The one library I created that may suffer from the problem described is Trellinator, which I recently began updating to work with the WeKan API, so maybe that should have been Kabanator … there’s still time.

But I don’t think calling them all after my favourite Futurama characters would have been a better choice.

Re: Software component names should be whimsical and cryptic

#87

Post by npteljes »

pavlov wrote: post #42
MrSqueezles wrote: post #24

Earlier quoted context omitted.

Yes. The advice is contextual. If you're making a public web framework, probably don't call it Web Framework. If you work at a company and you're writing the one and only hotel booking service, do call it Hotels instead of forcing your coworkers to memorize yet another cute name.

This only works once though. In ten years, none of the original developers of Hotels are with the company. The new generation of engineers is upset both with Hotels’ limitations and the fact that it’s not written in XYZ language which they really want to have on their résumés. So they embark on a total rewrite of Hotels, and to emphasize the awesomeness, most likely it will be called either Phoenix (because one out o…

They can also name it Hotels2. It's up to the people what they name it, some like cute names, some the descriptive.

Re: Software component names should be whimsical and cryptic

#88

Post by lupire »

ForHackernews wrote: post #54
anonymoushn wrote: post #32

Earlier quoted context omitted.

Red Hat Enterprise Linux and Amazon Web Services?

"Amazon Web Services" could mean literally anything. It only seems obvious and descriptive because it's become a widely known brand. Compare: "Nile Online Frameworks"

> Compare: "Nile Online Frameworks"

Those are synonyms. What is your point?

Re: Software component names should be whimsical and cryptic

#89

Post by lupire »

joantune wrote: post #10

Perhaps just give descriptive names and then change it when the scope changes?? "Problem" solved! Afraid of losing stars/dlds on the repo/etc? Make it clear in the Readme where the new project is. Have warnings et al for NPM projects. Ask npm/GitHub to allow name changes with redirects. This proposed "solution" is just bad for many reasons: You need to delve into the Readme to find out what it does. Imagine you're se…

Renaming is work that doesn't improve the functionality.

Re: Software component names should be whimsical and cryptic

#90

Post by Vinnl »

xupybd wrote: post #6

This is terrible advice. Cryptic names are horrible. It's a layer of cognitive overhead that no one needs. Yes if it gets so big that it's out grown it's original purpose that's a problem. But if it's really big people know what it is because it's big. If it's not that big rename it!

The point is that descriptive names tend to either be overly generic (also a cognitive overhead, especially when you have multiple such generic names), or too specific and therefore quickly inaccurate (and even larger cognitive overhead).

Oh, and as for "If it's not that big rename it" - this article is specifically about things that are hard to rename (e.g. public facing APIs or libraries):

> Now, if a name is going to be easily changeable forever, please do make it descriptive.

Post reply on HN