Software component names should be whimsical and cryptic
1–10 of 339 posts
Re: Software component names should be whimsical and cryptic
#2Also, unique. Or at least unique-ish.
Whoever named the ML thing "transformer" deserves a special place in hell. So many intriguing headlines, so few things worth reading. (I'm an EE, so I'm very interested in the other transformers. For some reason, the headlines for these things scan like they could apply to either. Alas, they don't.)
Re: Software component names should be whimsical and cryptic
#3Another reason is that people will _care_ about Shelob. It builds a community. They wouldn't care about an InternalWebCrawler.
Re: Software component names should be whimsical and cryptic
#4Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made. If you call your thing "ui-state-syncer" I'm going to suspect it's not really a big budget mainstream thing.
If it's called Vue, I'm going to think it's big enough that someone thought it was worth it to spend an hour thinking of names. It was intended to get big. This isn't some minimal internal thing for one specific use case that probably isn't mine. I'll be more likely to check it out.
They also limit the scope of a project. If you have a "datasender" people will say "This shouldn't preprocess data! This shouldn't compress! This shouldn't intelligently decide when to drop frames! It should just send!"
Now you gotta have a separate frame droppy preprocess thing, and the part that does communication has to tell it what kind of loss you have, but even that is not just sending data, so more likely you won't get that feature at all, or you'll have to go beyond the name.
If you hate features I guess it's a good way to make them hard to implement.
Re: Software component names should be whimsical and cryptic
#5My favourite example of how this can go sideways is BlueJeans - video conferencing software.
There's probably some cultural context I'm missing here, but I asked around in the office and got a different answer each time as to why it would be named like that.
That was 9 years ago and I still don't know BTW.
Re: Software component names should be whimsical and cryptic
#6This 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!
Re: Software component names should be whimsical and cryptic
#7If you went down the hell hole of microservices please do give descriptive names to services.
Re: Software component names should be whimsical and cryptic
#8I like a middle ground, which is to name things with somewhat-but-not-entirely related names. For example, our authentication service is the Keymaster, the CI service is the Pipeline Worker, etc.
That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
Re: Software component names should be whimsical and cryptic
#9There is this one man. He is great at marketing, and he once summed it up in just two sentences, but it's because he is so shockingly vain, vapid, and shallow that he is a genius at this art.
"I try to step back and remember my first shallow reaction. The day I realized it can be smart to be shallow was, for me, a deep experience."
I am not going to tell you who this is, but the point stands.
The name should be easy to pronounce, it should zing, and your first reaction should be positive. Why do you have it? Doesn't matter. It's either there or it's not.
A good name is at least half of a product's success.
Re: Software component names should be whimsical and cryptic
#10Perhaps 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 seeing a package.json and for each line you have to Google what's the project about
SEO is best if name matches.
These are enough *good* reasons why this advice is a bad idea