The author seems to be talking about names for two totally different things, lumping them under the term "component."
Whimsical project name? No problem.
Whimsical type name within a project? Really bad idea.
Whimsical variable name? Don't even think about it.
The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.
Bedazzling Names
Choose variable names with irrelevant emotional connotation. e.g.:
marypoppins = (superman + starship) / god;
This confuses the reader because they have difficulty disassociating the
emotional connotations of the words from the logic they're trying to think about.
> Now, if a name is going to be easily changeable forever, please do make it descriptive. I’d much rather maintain code where the variables look like numCols and numRows than i and j. (Just, for the love of God, if you change the meaning, also change the name). But if a name is going to serve as, in any sense, an identifier, something that will point at a big complicated thing from many places far away, make it an opaque identifier.
> Whimsical project names fall within a well-understood and used convention.
Boy, I wish!
I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
I was once tasked with extracting valuable IP from a legacy codebase where the developers had named all types after animals. So there was a SealService, a WalrusFactory, etc. etc. It was horrible and infuriating. They thought they were being cute, instead they just made everyone who ever looked at their code hate them with a passion.
Just in spite of this comment I'm going to name all my futures:
bitch_please
I invite spirited debate on this change request.
Is it an attempt to police the behavior of the async runtime? As a non-mainstream user of a minority language with pluggable runtimes, do I have the right to reappropriate this word?
Perhaps we can develop a language standard for async priority variable prefixes and suffixes. Removing it from the domain of library convention to language feature.
We currently utilize function parameters as the only input to functions, leaving a powerful source of information untapped on the left-hand-side. Will this change speed up development, or more likely, introduce errors? Will advances in language development environments reduce that concern?
How about:
bitch_please, bitch_now, bitch_after_next_slice
Note how the meaning of the variable changes with bitch_now? It feels more uncomfortable doesn't it? Less of a joke. Ignoring the runtime's own priorities and values changes this. But why is it less funny? What does that reveal about priorities and still-existing prejudices in LANG? Does that mean that the original use is also less funny in certain contexts, such as public spaces?
Alright, change withdrawn, I was wrong.
* This isn't an original joke, but it is further refined.
* I could have been a good academic or scientist.
I think a whimsical type name can have a sort of purpose. Sometimes a name goes from being descriptive to being prescriptive. It feels like a straightjacket, preventing you from adding code that would otherwise naturally fit there. In that case I think a whimsical name can be a good idea. Then later when the dust has settled, when you reach the top of the mountain and get a clear view of things, then you can revisit the name.
I'm not sure I agree with the first one either... I kinda can guess what BigQuery does - probably something with querying a lot of data, so if that's what I need to do, I'm going to check it out, but if not, I'd ignore it. But what does Splunk do? Who knows. Which of the projects with names Beam, Mahout, Samza and Flink I'd need to read about if I need to store and query a lot of data? And after I read about them, would I remember year later which of them does what?
> 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.
p.s. Obviously does not apply to brand names, which need to be distinctive.
> Create libraries that aim to do one thing and do it well.
That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like:
- css-min
- css-polyfill
- css-inline-min
- css-inline-polyfill
- css-script-min
- css-script-polyfill
- etc.
Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names.
And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
Also comes back to the thing of "products end up modelling the organisational structure".
If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService".
If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
> Create libraries that aim to do one thing and do it well.
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
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.
In theory, it makes sense that you would just create a new library with a better name, but if the original product has been on GitHub long enough to have amassed followers and a significant number of stars, they may be hesitant to have to ask those contributors to re-add the new repo.
Exactly. Don't just cram functionality into the closest thing at hand without any thought and you won't have to worry about scope creep ruining the name of that thing.
If you want to make new and different things, just do that.
Aesthetically, 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.
Seems that names for projects follow the same rule as troll names in the japanese light novel Overlord.
Short names, like "Gru" were reserved for the most powerful trolls because there were only so many combinations of three letters. Long names on the other hand were a sign of weakness and cowardice - bringing ridicule to those who introduced themselves like that.
As a counter example, there are plenty of successful projects/brands with highly descriptive names: TypeScript, RHEL, GitHub, AWS, GraphQL, HAproxy, Sendmail, QuickBooks, …
> Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made.
I think part of this is that in software ecosystems that have been around a long time, the most obvious descriptive name for a package tends to have been chosen by the package that got there first but is now has an API riddled with outdated anti-patterns and whose code hasn't been touched in a decade because eventually everything becomes a breaking change.
The newer package has to pick a weird-but-available name, but has the luxury of rebooting with a cleaner, simpler API and an implementation free of "bugs" that must be kept around in the name of backwards compatibility.
Once you experience enough of those, you subconsciously develop an association that "boring obvious name" equals "crappy API and weird behavior" while "weird random name" signals "nice modern API and coherent semantics". Of course, it's not always true, but humans are voracious pattern matchers and will create an association at the slightest hint of correlation.
Inside this essay giving horrible advice, is more horrible advice:
> Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those.
People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actually visualize how this all fits together.
It's like a children's song ...
The foot bone connected to the leg bone,
The leg bone connected to the knee bone,
The knee bone connected to the thigh bone,
The thigh bone connected to the back bone,
The back bone connected to the neck bone,
The neck bone connected to the head bone
And by the end of it you still don't know what you are dealing with.
This is a great diagnosis. I hate to assume things, but sometimes I almost get the impression that some software developers are pulling an "I am very smart" move by making things more cryptic than they need to be.
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.
I 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.
Everything in software (and life) is a trade-off and should be balanced and rebalanced. Something we just continuously fail to absorb in our true/false programmer brains, since everyone is always looking for those golden laws that always apply.
"Always give cute names", "Always give descriptive names", "FP is always good, OOP is always bad", "Always test first", "Always test later" etc.
Golden laws don't exist: Pick the best solution for your current situation and accept that your current situation will change. (Which is, again, a trade-off between now and the future!)
It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.
What is easier to understand at first glance?
Picard stopped responding to Luke. Bilbo is also down!
or
PaymentService stopped responding to UserService. Database-XYZ is down!
It might not be exciting but the cognitive load is much lower.
Except as the article says, names tend to stick, scopes don't.
This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
There is a real world example of a complex, critical, domain that has followed this approach religiously for years: prescription drugs. Every prescription drug is given an essentially nonsense non-proprietary (generic) name, with only broad categories identified by a stem (drugs ending in "mab," e.g., are monoclonal antibodies, those ending in "vir," are anti-virals). Names that are suggestive of medical target or use, beyond what is implied in the stem, are not allowed. The system is international, with international bodies ultimately approving naming of drugs.
The result - well, it works in some respects, but it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer, or that it plays much role in getting the right prescription into the right medicine cabinet and ultimately, patient. The names are confusing as hell, often unpronouncable (despite the orthographic and oral qualities of the names being considerations in name assignment) to anyone who doesn't know them well, professionally. And the common drugs - well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
I've been on medication for years, and I still can't pronounce let alone remember it's name. God help me if it becomes critical I tell someone what it is, because I'm screwed if so.
> well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
The part missing here is that there's a doctor in the middle that knows about the "atorvastatin" part, and that's usually who prescribes you the Lipitor.
Another part is that the name should be a) unique, so you could make it a trademark, b) distinct, so the patient won't tell their other doctor they take a wrong drug (less important now with electronic databases but still important) and c) shouldn't mean anything to the patient, because they aren't the one deciding whether to take it or not - but they will be the ones taking it.
That's usually not the case with software packages. Of course, sometimes it is the case that the manager decides to buy software because it sounds good without technically understanding what it actually does - but it's not a common case, especially for more technologically complex software. So the naming considerations here are very different.
That's actually a great example and it illustrates OP's point. If prescription drugs were given names based on their perceived meaning or target, things could get extremely confusing and/or misleading later when the meaning or target change (but the name stays the same).
As it stands, choosing "random" names definitely seems like the lesser of two evils. The names may seem awkward at first but once you get used to them there's nothing particularly bad about them.
> it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer
In this case I don't think you can have the cake and eat it too, unless you can somehow prove that the chosen descriptive name will forever remain meaningful and descriptive.
“Descriptive” names don’t create transparency, they create the illusion of transparency.
...some of the time. The rest of the time they're actually very useful. Giving up any attempt at having a descriptive name just in case you get it wrong is throwing the baby out with the bath water.
What's probably happened with a lot of poorly named projects is that when the scope changed to make the name redundant there was no attempt to change it. People get attached to their project names. It's possible that changing the name would require some effort, and maybe some cost (losing Github stars maybe?). That makes people stick with bad names. None of these things apply in a company. Just change the project name to reflect what it does now.
Here I'm with the OP. A descriptive project name is hard, and gets lost among projects of a similar nature.
Try to come up with descriptive names for projects like Git, Node.js, Docker, well, Linux. Well, BSD is formally a descriptive name, but it elucidates little.
Of course there are some examples of somehow descriptive names which seem natural because of the sweeping success of the product: Photoshop, React. But they are few and far between.
In short, project names are closer to branding than to engineering.
Inside a codebase names should be descriptive, and appropriate effort should be allocated to name key things in an elucidating manner; nothing to debate here. But it's a very different context.
While I agree the extreme is clearly bad, I would also challenge if any project ever succeeded on any virtues of it's name. Such that I would see this as a very low stakes decision.
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 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
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.)
I like the distinction between tools and products here.
If it's a product, by all means think about brand including a creative name. Might be vaguely related to the service, like YouTube, or completely wild, like Starbucks.
If it's mostly a tool, being descriptive is just good SEO. You are not ever becoming a "household name" with a recognizable name when you are just supplementing a library supplementing a framework (or similar), and there is no reason to strive for that. "Django REST framework" shows up naturally when I google "django rest" and that just benefits both sides.
If you are in between the two, opt for the middle: TweetDeck, MailChimp.
I have doubts about the author's overall point, but something to consider is how does a name help/hinder search? A name that's overly mundane, say, "Go", becomes problematic to google (hence the need to search for "golang" or add other terms).
I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO.
Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
I hereby dub this "The Protectiva Paradigm" - an injunction to name things whimsically, not descriptively because a) its fun and b) the function of the thing changes so "give yourself wiggle room".
I strongly agree with this. I’ve worked places that follow both naming styles and I’ve found it’s much easier to get up to speed if the services and repositories have names that don’t overload the language you use to talk about what you’re doing. E.g. if your service that sends out webhooks is called “webhooks”, then newcomers will always be confused about whether you’re talking about the concept or the implementation; if the service is called “voltron”, newcomers might not know what it does initially, but they can discover that pretty quickly.
The throwaway comment about not using diagrams was truly baffling to me.
A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane / activity diagram shouldn't have two-way arrows in it (what would that mean?).
How is that more likely to be read wrong than source code? Doesn't match my experience at all.
And no pesky scope implied by the name! Now, each of the components can grow in a truly unconstrained manner, enveloping whatever random features were slightly more convenient to add there instead of in a new component. Amazing!
[+] [-] yuan43|3 years ago|reply
Whimsical project name? No problem.
Whimsical type name within a project? Really bad idea.
Whimsical variable name? Don't even think about it.
The concept the author is missing is "convention." Whimsical project names fall within a well-understood and used convention. The convention for type and variable names, however, is set by the standard library and these are almost always descriptive. Their purpose is, in the best case, to reinforce a ubiquitous language drawn from the domain.
[+] [-] kogus|3 years ago|reply
Especially this bit:
[+] [-] lifthrasiir|3 years ago|reply
The author is very clear about this matter.
[+] [-] ThePadawan|3 years ago|reply
Boy, I wish!
I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.
[+] [-] noworriesnate|3 years ago|reply
[+] [-] bcrosby95|3 years ago|reply
Even though I played the game I was pretty lost in that codebase. People that didn't play had no idea what anything did.
[+] [-] blowski|3 years ago|reply
[+] [-] jgerrish|3 years ago|reply
bitch_please
I invite spirited debate on this change request.
Is it an attempt to police the behavior of the async runtime? As a non-mainstream user of a minority language with pluggable runtimes, do I have the right to reappropriate this word?
Perhaps we can develop a language standard for async priority variable prefixes and suffixes. Removing it from the domain of library convention to language feature.
We currently utilize function parameters as the only input to functions, leaving a powerful source of information untapped on the left-hand-side. Will this change speed up development, or more likely, introduce errors? Will advances in language development environments reduce that concern?
How about: bitch_please, bitch_now, bitch_after_next_slice
Note how the meaning of the variable changes with bitch_now? It feels more uncomfortable doesn't it? Less of a joke. Ignoring the runtime's own priorities and values changes this. But why is it less funny? What does that reveal about priorities and still-existing prejudices in LANG? Does that mean that the original use is also less funny in certain contexts, such as public spaces?
Alright, change withdrawn, I was wrong.
* This isn't an original joke, but it is further refined. * I could have been a good academic or scientist.
[+] [-] im3w1l|3 years ago|reply
[+] [-] smsm42|3 years ago|reply
[+] [-] danielvaughn|3 years ago|reply
[+] [-] ttiurani|3 years ago|reply
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.
p.s. Obviously does not apply to brand names, which need to be distinctive.
p.p.s. Rich Hickey talks about this here: https://www.youtube.com/watch?v=oyLBGkS5ICk
[+] [-] Vinnl|3 years ago|reply
That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like:
- css-min
- css-polyfill
- css-inline-min
- css-inline-polyfill
- css-script-min
- css-script-polyfill
- etc.
Good luck clarifying what you're talking about. And of course, people will start using acronyms for all of them, and now you're back at cryptical names, with the added benefit of all the names sounding and looking similar. Or, of course, have inaccurate or inconsistent names.
And then I didn't even get to the part where your categorisation turns out to not match the eventual scope, and they'll need to be split into css-server-min, css-client-min, etc.
[+] [-] another-dave|3 years ago|reply
If it's painless to create new internal products within your company & there is operational support for it, you're more likely to spin up a sister "EmailNotificationService" alongside "SmsNotificationService".
If you have to jump through hoops to get sign-off and business cases etc and eitherways it's the same team responsible for both, people are more likely to say "let's just put the functionality in here"
[+] [-] habitue|3 years ago|reply
This is a thing people like to repeat over and over again, but just really isn't actionable. The world is very high dimensional, it's always a judgement call what to cluster together and call "one thing". Especially in software where everything is made up and is constantly changing.
People often like to refer to things like unix tools etc as doing one thing and doing it well, but all those tools have grown a ton of command line args, and have backwards compatibility issues that prevent them from doing their job "well" in the modern era. So people write new tools or just hardcodes a ton of command line flags into aliases by default. Many default settings on unix tools are awful. Why does grep not use regex by default? Why doesn't echo support newline escapes by default? Which tools use color by default?
Reality is a mess, and it's an illusion that you can do "one thing"
[+] [-] etothepii|3 years ago|reply
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.
[+] [-] JosephGuerra|3 years ago|reply
[+] [-] jayd16|3 years ago|reply
If you want to make new and different things, just do that.
[+] [-] hulitu|3 years ago|reply
[+] [-] eternityforest|3 years ago|reply
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.
[+] [-] Tade0|3 years ago|reply
Short names, like "Gru" were reserved for the most powerful trolls because there were only so many combinations of three letters. Long names on the other hand were a sign of weakness and cowardice - bringing ridicule to those who introduced themselves like that.
[+] [-] e1g|3 years ago|reply
[+] [-] munificent|3 years ago|reply
I think part of this is that in software ecosystems that have been around a long time, the most obvious descriptive name for a package tends to have been chosen by the package that got there first but is now has an API riddled with outdated anti-patterns and whose code hasn't been touched in a decade because eventually everything becomes a breaking change.
The newer package has to pick a weird-but-available name, but has the luxury of rebooting with a cleaner, simpler API and an implementation free of "bugs" that must be kept around in the name of backwards compatibility.
Once you experience enough of those, you subconsciously develop an association that "boring obvious name" equals "crappy API and weird behavior" while "weird random name" signals "nice modern API and coherent semantics". Of course, it's not always true, but humans are voracious pattern matchers and will create an association at the slightest hint of correlation.
[+] [-] Ensorceled|3 years ago|reply
> Even worse are those ubiquitous diagrams everybody uses to communicate about software, where there’s a box labeled OrdersService with an arrow connecting it to a box labeled OrderStatusService. I don’t understand why anybody draws those.
People like this are why there are documents with a thousand bullet points and no diagrams to help anyone actually visualize how this all fits together.
It's like a children's song ...
The foot bone connected to the leg bone, The leg bone connected to the knee bone, The knee bone connected to the thigh bone, The thigh bone connected to the back bone, The back bone connected to the neck bone, The neck bone connected to the head bone
And by the end of it you still don't know what you are dealing with.
[+] [-] silent_cal|3 years ago|reply
[+] [-] xani_|3 years ago|reply
[+] [-] motohagiography|3 years ago|reply
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.
[+] [-] stavros|3 years ago|reply
That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
[+] [-] jeroenvlek|3 years ago|reply
"Always give cute names", "Always give descriptive names", "FP is always good, OOP is always bad", "Always test first", "Always test later" etc.
Golden laws don't exist: Pick the best solution for your current situation and accept that your current situation will change. (Which is, again, a trade-off between now and the future!)
[+] [-] cbushko|3 years ago|reply
It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.
What is easier to understand at first glance?
Picard stopped responding to Luke. Bilbo is also down!
or
PaymentService stopped responding to UserService. Database-XYZ is down!
It might not be exciting but the cognitive load is much lower.
[+] [-] eipipuz|3 years ago|reply
This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"
[+] [-] teeray|3 years ago|reply
PPS stopped responding to UDMS. CMS is also down! No, not the CMS, the CMS is fine… CMS-the-service is down!
[+] [-] walnutclosefarm|3 years ago|reply
The result - well, it works in some respects, but it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer, or that it plays much role in getting the right prescription into the right medicine cabinet and ultimately, patient. The names are confusing as hell, often unpronouncable (despite the orthographic and oral qualities of the names being considerations in name assignment) to anyone who doesn't know them well, professionally. And the common drugs - well, let's just say, you're far more likely to tell someone you're on Lipitor (a brand name, for marketing) than "atorvastatin".
[+] [-] kemiller2002|3 years ago|reply
[+] [-] smsm42|3 years ago|reply
The part missing here is that there's a doctor in the middle that knows about the "atorvastatin" part, and that's usually who prescribes you the Lipitor.
Another part is that the name should be a) unique, so you could make it a trademark, b) distinct, so the patient won't tell their other doctor they take a wrong drug (less important now with electronic databases but still important) and c) shouldn't mean anything to the patient, because they aren't the one deciding whether to take it or not - but they will be the ones taking it.
That's usually not the case with software packages. Of course, sometimes it is the case that the manager decides to buy software because it sounds good without technically understanding what it actually does - but it's not a common case, especially for more technologically complex software. So the naming considerations here are very different.
[+] [-] Tomis02|3 years ago|reply
> it would take a real optimist to say that brings any clarity or long term order to the process by which medical professionals learn or refer to the drugs they prescribe and administer
In this case I don't think you can have the cake and eat it too, unless you can somehow prove that the chosen descriptive name will forever remain meaningful and descriptive.
[+] [-] onion2k|3 years ago|reply
...some of the time. The rest of the time they're actually very useful. Giving up any attempt at having a descriptive name just in case you get it wrong is throwing the baby out with the bath water.
What's probably happened with a lot of poorly named projects is that when the scope changed to make the name redundant there was no attempt to change it. People get attached to their project names. It's possible that changing the name would require some effort, and maybe some cost (losing Github stars maybe?). That makes people stick with bad names. None of these things apply in a company. Just change the project name to reflect what it does now.
[+] [-] nine_k|3 years ago|reply
Try to come up with descriptive names for projects like Git, Node.js, Docker, well, Linux. Well, BSD is formally a descriptive name, but it elucidates little.
Of course there are some examples of somehow descriptive names which seem natural because of the sweeping success of the product: Photoshop, React. But they are few and far between.
In short, project names are closer to branding than to engineering.
Inside a codebase names should be descriptive, and appropriate effort should be allocated to name key things in an elucidating manner; nothing to debate here. But it's a very different context.
[+] [-] taeric|3 years ago|reply
[+] [-] joantune|3 years ago|reply
"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
[+] [-] exmadscientist|3 years ago|reply
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.)
[+] [-] blackbrokkoli|3 years ago|reply
If it's a product, by all means think about brand including a creative name. Might be vaguely related to the service, like YouTube, or completely wild, like Starbucks.
If it's mostly a tool, being descriptive is just good SEO. You are not ever becoming a "household name" with a recognizable name when you are just supplementing a library supplementing a framework (or similar), and there is no reason to strive for that. "Django REST framework" shows up naturally when I google "django rest" and that just benefits both sides.
If you are in between the two, opt for the middle: TweetDeck, MailChimp.
That's my two cents anyways..
[+] [-] msluyter|3 years ago|reply
I feel almost like there's an analogy between choosing names for packages/projects and bird calls. Birds need to make their calls stand out in a given ecosystem. If you have a dozen projects like, say, "object-mapper," "object-db-mapper," "object-mapping", "object-mapper-thingy", "object-mapping-service", "db-object-mapper", it's hard to remember wtf was the one you need. If in such an ecosystem your project was named "Orangutan," it might stand out and be noticed. OTOH, if all projects in a given ecosystem have weird names like "murano", "swift", "glance", "hotdog", "gorilla", "zaqar", "cthulhu", "funky-chicken", "Sauron" or whatever, it may be hard to remember what they all do/mean -- yes, I'm giving you the side eye, openstack. In such a space, "cloud-disk" or something might win, IMHO.
Slightly tangentially related is the use of odd words in log messages to aid searchability. I've been grateful for misspellings in the past, so I could easily grep for some critical log message containing `transation_id` or whatnot. (Good struct logging makes this less necessary, thankfully.)
[+] [-] javajosh|3 years ago|reply
The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. https://dune.fandom.com/wiki/Missionaria_Protectiva
[+] [-] fiddlerwoaroof|3 years ago|reply
[+] [-] samatman|3 years ago|reply
A dashed arrow pointing in one direction is async data flow in that direction, A solid arrow is synchronous, and a swimlane / activity diagram shouldn't have two-way arrows in it (what would that mean?).
How is that more likely to be read wrong than source code? Doesn't match my experience at all.
[+] [-] phdelightful|3 years ago|reply
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)
[+] [-] qaq|3 years ago|reply
[+] [-] RcouF1uZ4gsC|3 years ago|reply
This way no one is misled by the name. Also, there is much less chance that an offensive name gets picked (either intentional or unintentionally).
There is also much less risk of collisions. In addition, you don’t waste any time trying to come up with a name.
[+] [-] sebastos|3 years ago|reply