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.
I did this in an infosec class in undergrad 15 years ago, inspired by exactly this essay. The first part of the project was to write a program that password protected a file, and the second part was to try and break each other's programs, with full source code access. I think it helped discourage people from trying to deal with mine as opposed to other people's. (Also, several people correctly guessed that it was mine despite the code being nominally anonymous...)
This thing is gold. But i think that he misunderstood his audience or the audience did not read till this "This essay is a joke! I apologise if anyone took this literally. "
There are a lot of Google and Microsoft programs who implemented his "advice" (i don't use Apple).
> 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.
If you call your data exporter "Asparagus" I will throw a thesaurus at you every day until you come up with a better name for it that has some kind of mnemonic link to what it does. "Data Exporter" is okay, but "Catapult" or "Superhighway" or another whimsical name would be okay too, so long as it loosely matches the problem domain in a memorable way.
Your comment really gave me pause. I've used FileMaker for many years but never gave the name that much thought.
I can't say how the name was chosen. But, I believe I understand the justification for it. It is pretty straightforward once the metaphor is clear. The files it is making are the type of files that go into filing cabinets, not the files on a computer. Early versions of the software had a logo/picture of a building that was a giant filing cabinet and the app logo has usually been a filing folder.
The name makes sense in that isn't about making files on a computer but to help small business convert physical files found in filing cabinets into digital ones in wysiwyg database.
I remember finding "Photoshop" nonsensical at first because I associated a shop with a place to go buy things and it only made sense once I made the association that cars and such are taken to the shop for repairs.
I've worked on tools that were slightly misnamed after 6 months, and completely misnamed after 2 years. At that point they were also usually just nearly useless due to feature bloat and/or lack of scalability, so deprecated or replaced with something better.
They didn't change names, but their successors would get a new one.
Isn't it even harder to re-define names in a company? There might be 3 people involved in re-definition, but it affects 15 people.
How are we going to notify those 15? Do we even know who those 15 are? Are we going to create a weekly redefinition newsletter?
I think in most cases new meaning deserves a new name. Everything else is just hacks.
How hard is it to change a name is a actually a really good metric for a company. If a simple rename takes several days, multiple approvals, rounds of QA, and a scheduled release next quarter, then you probably need those hacks.
I think that's very extreme. Products grow at a gradual pace. I don't think there are defining moments when a product no longer supports something, or is no longer used in a way that it was intended to.
I would argue it's easier to maintain peoples understanding of a product since that will also be done gradually. It's not easy to update naming inside of a code base without potentially breaking software significantly or causing unknown bugs elsewhere. I think most software would fail the renaming test. It's also generally not worth the money and time needed to make that change.
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?
Probably not by itself but it isn't that fundamentally different from some language conventions allowing/preferring glyphs over words for certain meanings eg `string->int` rather than `stringToInt` or whatever.
> 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.
And then someone makes a package to combine all of them, and then someone makes a package that combines that combining package with another combining package, and then the author of `css-script-polyfill` deletes the repo, and we're dealing with another leftpad
I can't be the only one that just includes any dependency with a permissive license? `git subtree` is so ridiculously easy for the larger dependencies and 90% of these projects are sub-500 lines in a single file, just include them.
> you're going to have a list of hard-to-distinguish projects like:
What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need.
Now, let's imagine your list is "creatively" named like
- shelob
- arcana
- custard
- escalope
- virtuocsso
- jester-css
- etc.
Ah yes, this is so much easier to distinguish, isn't it?
They're hard to distinguish in the sense that a colleague might ask something like "hey can you publish a new version of css-script-min" and you accidentally publish a new version of "css-min" or "css-inline-min" or whatever instead.
A name is usually not enough to determine which library/framework is best for you. This is the _illusion of transparency_ that the author talks about. How would you rename React and Angular such that developers could tell at a glance which one to use? If it's going to require further investigation from the user's part, better to give the project an opaque name to make it clear that further investigation is necessary.
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.
I was literally - minutes ago - watching Overlord then saw this message just now. Small world sometimes. Rich world building that it can be referenced easily.
As a counter example, there are plenty of successful projects/brands with highly descriptive names: TypeScript, RHEL, GitHub, AWS, GraphQL, HAproxy, Sendmail, QuickBooks, …
I'm assuming this is a tool for quickly laying out and publishing books. Or perhaps a tool for quickly searching for and downloading books to my iPad or ebook reader.
At least there's a meaning of word "book" that matches what it does. So once you learned what it does, you can make a mental note of "ah, those books". Imagine it was named FluffyTurtle instead. Good luck remembering what it does even if you already looked it up 20 times before. And not confusing it with SparklyCamel, which is an inventory manager for plumbers.
But accounts and bookkeepers all know what QuickBooks is and are quite happy to not have to explain to their clients why they need to spend $75 a month on "KowalaBabyPooPoos" or something equally ludicrous name.
Which is the point which you probably didn't miss in the first place.
I abbreviated on the phone, but the respective full names are “X Enterprise Linux” and “X Web Services” which are literal description of what their thing is. “RedHat” and “Amazon” are generic, but the product names are highly specific.
I mean it could’ve been “RedHat Cthulu” and “Amazon RainBox”.
AWS was useful until it became to mean "about 9000 totally unrelated products, each of them having its own name, sometimes very non-descriptive". But at least you know it's a service from Amazon, sometimes you don't even get that from the name.
> 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.
The ones who do that I've found to be less experienced. Once they've had to deal with their own bullshit, they tend to grow out of it. Even you don't know what that code you wrote a year ago is doing.
Yeah, the first couple of "I wish I could go back in time to my past self and punch that smug asshole right in the mouth for being too smart for my own good" moments cure that out of you, usually.
If within the same system, you have multiples of "personService", "paymentService", and none them have unique features that can be used in the name, then you probably have a design problem.
Qualify the duplicate name with why you have a duplicate.
Already have Service and need Service? How bout NewService and Service instead. Or ${NEW_TRAIT}Service and Service. (can replace Service with any domain)
You could also just not duplicate and keep a single Service. Like other mentioned this is likely a design problem at any point names clash.
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?"
I would not say top level design. Software is often born out of software. It's more like a woman keeping her children in her womb instead of giving birth to them.
I don't think somebody would be more confused to learn that payment service also deals with fraud (which is something a lot of people are aware of - every payment service on the face of the planet has now warnings about fraud) than having to deal with "Picard is not connecting to Bilbo because Legolas is refusing to pass KrumpleSnitch to Kthulhu". In fact, I'm not sure it's humanly possible to be more confused than dealing with something like that.
And if you having a payment system that starts doing something payments systems traditionally don't do - like, I dunno, predict weather? - then you have a design problem and should refactor your system so your payment system doesn't do that anymore.
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.
> 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
a) The official (that is, generic) drug name is guaranteed to be unique, but they cannot be trademarked. That's one part of why drugs are typically marketed under names other than the official name ("Lipitor" is a market name, "atorvastatin" is the actual drug name).
b) Most patients don't know the names of the drugs they are taking, and what they do know are as often as not, not the official name, but a marketing name. Ask any doctor why they ask patients to bring their prescriptions with them to office visits (hint: because in m any cases, it's the only way to get an accurate picture of what a patient is actually taking.)
c) I don't follow this at all. It's a bad think that I know that the three drugs I take are a diuretic, a beta blocker, and an angiotensin receptor blocker?
I think it's interesting to compare drug naming with other medical interventions. We don't call a Laparoscopic Cholecystectomy a "gandalf" or "vartafoprodson." We use medically meaningful names. Why is "losartan" better than "angiotension receptor blocker 95-1" (first ARB approved in 1995)?
I am being regularly asked by my healthcare provider which drugs I take, on each visit's checkin. They'd be happy to have the Rx, but in many cases the patient doesn't even have one - it's buried somewhere "in the system", and if you change providers, you don't get anything from the old one - hopefully the new one knows how to talk to the old one to get the info. So there's nothing to "bring" to the office.
> It's a bad think that I know that the three drugs I take are a diuretic, a beta blocker, and an angiotensin receptor blocker?
No, it's not a bad thing that you know that, it's just about 99.999% of people have no idea what a "beta blocker" is. So for them that information is completely useless, moreover, if they plan to act on it, it may be dangerous, because they may confuse "beta blocker" with some other "blocker" and make some important decision based on that, without understanding the real consequences. If you are knowledgeable enough to know what "beta blocker" is and how it works - sure, it's useful for you, but vast majority of people don't know that and never will.
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
Only is you see "functionality" as "code being run in production". A lot of things then don't improve "functionality" - design documents, comments, use cases, tests, documentation, tutorials, etc. Proper software project still does all of it.
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.)
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).
The EE transformer was one of a few devices when it was created. It was not part of a field that had already hundreds of concepts with that same name, including a concept that describes everything that looks like a ML transformer.
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).
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.
Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user.
Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?
You're right about the external interface, but you still need to give a name to the actual service behind the URL.
From your point on versioning, I'd assume you'd actually call it UserProfileV2 ?
PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
It depends on the language, but I would probably call it `UserProfile` and change a major version even if it's in an entirely different language. Maybe even kept in the same repo.
> PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
From what it said in the original comment, it still seems like a user profile to me.
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!
If your functionality breaks the description, rename the software, or outsource the new functionality into a plugin or a new software. Pure Cryptic names are just cancer, even more than software which has grown out of its descriptive naming.
There 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.
If i see the words "whimsical", "delightful" or {insert emoji} on a project readme, I will instantly dismiss that project. I've learnt not to trust such projects.
Naming things is hard. I still get it wrong after a decade+ of building complex systems.
Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress.
If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load.
On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good.
You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).
In our stock trading algorithm, a parent order could have multiple child orders. If the parent order quantity was amended down, it might be necessary to cancel some of the child orders. The function name for this was called getSophiesChoice()
OK, I guess I'll have to argue against. Please don't make component names whimsical. Your idea of whimsy and fun is potentially confusing or (worst case) offensive to others. Yes, make them unique and searchable. Yes, make them memorable and pronounceable. Yes, make them SFW.
It would get tiring to have to keep explaining to new team members that our prime number generator is named "optimus" even if it was initially clever.
I don't look forward to convincing my boss we need to pull in "libAnimeBabe" as a dependency even if it's the best parser for a file format we need to import.
Nobody wants to find out a year after all of our marketing material is put together that our software name means "asshole" in another language.
Don't make me have to pronounce an unpronounceable Gaelic word every time I do a presentation on our software stack because you're Irish and just had to name your component that way.
There are lots of ways "whimsical" can backfire unintentionally. Save your creativity for the actual software solution.
Sorry but a prime number generator called "Optimus" is an awesome idea.
I also kind of disagree that an "unpronounceable Gaelic word" is a poor choice. Seems like cultural discrimination. People all over the world write software, not just people who can pronounce English words.
This is the absolute antithesis to how I operate and I disagree almost to the point of being offended.
Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ
For me that is not a parody, it's lived experience.
> I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.
When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.
Did you read the full essay? The author agrees with you regarding your ideals. The essay is a concession to reality. I’ve seen wildly out of date readmes that cause more confusion than help, for sure, too.
I don’t care if you name them descriptively or weirdly, just please name them distinctly so when I have to do searches for them I come up with the right thing. The worst is Apple’s “Pages” and “Numbers”. Try doing a search for how to do something in either of these products. These are far from the only examples.
> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is.
I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will say that funny names are not actually fun.
I can only imagine working in the author's ideal company:
"Hey, does anyone know why Shmoop is down? I know I updated the BoomBoom and reconfigured Thanos, but now Klomgan is reporting a series of Lemonhead warnings. Should I talk to Meep team or the Chumbawumba admins?"
> I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone else what should be fun for them... except in this case, where I will say that funny names are not actually fun.
I worked in a company that would "break ground" a new microservice every other week with overlapping scope of other microservices. (poor planning in resource allocation), which lead to some services named after Greek mythology that loose describes what service does...sometimes... Then they started giving more descriptive names, services that just do X and named X, except later they started doing Y, and now it's confusing.
Then we had service XYZ (abbreviated from what it supposed to do), it took too long to build, so naturally management decided to make a Z service and remove functionality from XYZ.
I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.
>I think the author comes from a similar place where scope for service is constantly changing, and silly names are the only source of dopamine.
Upon the recognition of this is the time you should have your resume updated and you start responding to some of those LinkedIn reps that have been emailing you.
I know this doesn't really advance the discussion that much, but... if you haven't seen this Krazam video, it's a sketch about that exact sentence there:
I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if it succeeds or fails.
You chose childish names one'd presumably be embarrassed to say to an outsider, but... Assuming you can stomach saying the project's name out loud, what's to lose?
What method would you propose teams used to name a project, in which "fun" names are discouraged?
Klomgan? This argument is a straw man because those names are all ridiculous and defeat the purpose of the naming strategy. If a real organization adopted the naming strategy described by this article, reason would quickly become a part of it, and all those names would therefore be disqualified. Nobody knows what a Klomgan is and it's a made-up word that's difficult to pronounce. Why would anyone suggest it? How about marshmallow, lemonade, candlestick, or zephyr? Those are some simple dictionary names that are easy to say and aren't overly distracting or offensive.
Maybe "whimsical" isn't an accurate moniker. Generic or Common is how I would label the naming strategy described by this article. "Whimsical" is just asking for trouble and opens you up to overtly stupid names like "Chumbawumba."
Well, Shelob has no meaning to me. And yes, I know now where it comes from, but I haven't read the books.
The article says "names should make you smile." And really, does anything make a person smile more than Chumbawumba? They get knocked down, and they get up again!
As someone who's working on a project right now that's full of whimsical/cryptic names (project is called Sandman, modules within the project include Mystic, Hypnos, Lethe, Morpheus, Dreamer, and Lucid), this was validating to read. That said, if my project was anything more than a solo personal project, I'd only keep the Sandman top-level name and rename the modules to things like Parser, Server, Client, etc. to make them more maintainable by others. I keep them because I'm the only one working on the project and I quite enjoy the sense of Hollywood-hacker-montage they impart me when I'm debugging.
I larelt agree. I wrote a while back about how to make good names[1]
Choosing whimsical names is a pretty good way to satisfy my two most important requirements. They are often unique and don't mislead people.
Of course my ideal name would also give some hint about what it does (I think Google's BigTable may be one of the best named products) but I think this is far less important than the other two requirements.
I agree with the author but for different reasons.
Software should be fun! I love it when packages have goofy names. If I can shitpost with the language I'm going to get just a little more invested in it.
And to be honest, even the 'serious' names fail at connoting respectability to begin with. Your grandpa would get annoyed just hearing the word 'containerisation' - and not just because he thinks computers are for nerds. The word sounds silly. People are saying this silly word at conferences and the word is still silly. So why not lean into the goof?
Had a thing where the function that gave the user activation feedback was called "SparklePonies". Others found that confusing, especially people whose first language was not English.
I can't believe I'd never thought to look up what grep stood for, or if I had it had failed totally to make an impression on me. But it doesn't even make any obvious sense - "global regular expression print"??
OTOH "git" doesn't stand for anything. "Cat" is rarely used to concatenate, "awk" you'd never guess unless you looked it up, "perl"'s status as an acronym is purely apocryphal etc. etc.
This is bullshit. I don't want dopamine hits. I want money for my code. And guess what increases the money I get from my code? Naming stuff consistently with their meaning.
Strong "Death of Perosnality"[1] vibes here! That was about ux, this is more about dx. In that thread I advocated pretty heavily for apps not being special[2], for their best service usually being to get out of the way, to be slim & light, focused less on initial charm & more on enduring usability.
I think most of that applies here. The whimsy & fun is cute at first, but it's rarely long term magic. For new teams & outsiders, it's a pain. I've had to work eith a sync engine where there's 20 subsystems seemingly each named by randomly picking a name from Encyclopedia of Mythology. There's probably something cute & creative & whimsical to the authors, but as someone trying to use the thing, it's merciless & oppressive, a huge turn off.
For an external/public project? Sure! For a release code name (like Debian does), yeah why not. For internal service names? No. Not unless there's an obvious connection to its role (ie: TrafficCop handles DOS attempts, etc)
I'm working with some legacy code that followed this pattern for internal services. It's a nightmare. WTF is Bilbo, oh it handles 2fa? And what's Pippin again? And there's a dozen other examples, of course most of them are from LOTR. I literally have to maintain a mental mapping because there's no rhyme or reason to the choices.
That's actively anti-developer, anti empathy and I hate it. It's not cute, fun, helpful, professional. I can't think of a single redeeming quality. Maybe it's ok for a prototype you intend to throw away because it's so ridiculous you don't want to use that name with your boss, so it encourages non attachment.
If you really can't pin down a name that describes the thing you're making, maybe you don't know what you're making?
Also, we can rename and/or retractor things. And we should if their responsibilities change!
Edit: added distinction about internal vs external.
I work at a company where all of our services have stupid Greek code names. It adds a layer of obscurity, increases the cost of onboarding devs and context switching, etc. It's a goddamn stupid idea.
The author here is equivocating opaque code names with multi-use repos. They're saying "see!? some repos on github do things in addition to their literal name."
That has nothing to do with the fact that obscure code names are a stupid anti-pattern.
I very often whip out this tried by true joke. People often think it's "just a joke", but I actually think of it more as an adage, as words of wisdom, that also just happen to be whimsical.
There are only 2 difficult things in computer science:
1. Naming things
2. Cache Invalidation
3. Off by one errors
The number of times I've told it in an interview with a programmer and they don't laugh are horrifying. There's deep, memorable wisdom in there if you have any experience.
A handful of examples don't prove anything. If a Widget Lookup Service is used to lookup widgets for its entire lifespan, calling it Frodo isn't doing anyone any favours.
And it's not like "oops some gadget polishing code fell into my widget lookup service": don't put inappropriate crap into your solution. Little discipline goes a long way.
Does knowing that it is called "Widget Lookup Service" actually convey enough information to you to be able to make meaningful changes to its implementation? If not, then its time to look up it up in your internal company wiki. Which name will yield search results specific to the service you are interested in, and which one will be heavily polluted by mentions of "Widget", presumably something common in your domain.
This reminds me of a "problem" we had in a code base that we maintained. It was a test framework written (and I use the term loosely) in perl. Someone wrote a throwaway script which later grew like a mould into a "tool" that was used by a large business group. None of the maintainers (including myself) knew perl properly. Of the 8k odd lines, 5k was a single function descriptively called `run`.
All the variables were global since there were not functions to pass things into and we had a problem similar to what the OP posted about using variable names that someone else might be using somewhere else. One thing we needed was `machine_type`. There were some references to `MachineType` and `machine_type` and `machineType` so, a colleague decided to use the name `MaChInEtYpE` to make it unique. For all I know there are still people who trip over themselves on the keyboard typing this while maintaining it.
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.
Everyone else beat me to the explanation. The "Murphy" in Murphy's law also worked specifically on RocketSleds which is where the term "Murphy's Law" came from:
"Following the end of hostilities, in 1947 Murphy attended the United States Air Force Institute of Technology, becoming R&D Officer at the Wright Air Development Center of Wright-Patterson Air Force Base. It was while here that he became involved in the high-speed rocket sled experiments (USAF project MX981, 1949) which led to the coining of Murphy's law."
I was very pleasantly surprised by this coincindence when I was looking for a name for my testing package to go with my RocketSled framework. I named the framework RocketSled before I wrote the testing package, with no idea about the history of the term Murphy's Law.
Interesting side note: murphytest lives on to this day as an NPM package, I still use the same approach to testing stuff now (ie. not worrying about any of the tenets of "Unit Testing", a practise which I called "Convergence Testing" at the time, but which probably already has a name, like Integration Testing maybe).
"Descriptive" names like in the article might not be a good fit, because they're just badly chosen and sometimes lie to you.
I'd argue that actually descriptive names aren't the worst thing ever, I wouldn't mind seeing a project/source code repo named "Client Bill PDF Generator" as long as the name on the tin actually matches what's inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary.
What this avoids is the problem of not needing a glossary to figure out what "Shelob" is supposed to be in a list of 50 different services, though I guess if you wanted to go for something fun, might as well throw them together: "Shelob: Client Bill PDF Generator".
It's kind of how I approach naming my homelab servers/saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name/monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where "fun" names make sense.
Actually, Dylan Beattie once described why "fun" names might make sense, in a conference talk called "Life, Liberty and the Pursuit of APIness : The Secret to Happy Code", though it also touched upon other aspects of development.
The argument went along the lines of "by giving it a name, you cut out a lot of the noise". Curious, I can kind of understand that point of view, even though I'm not inclined to fully agree with it.
I came up with the idea with my first PC to name my computers after Popes (skipping the numbers). That computer was named Peter. To be honest, I could not tell you the name of the laptop I’m typing this on right now without looking it up. So much for a clever naming scheme being useful.
Cryptic names will only have one outcome. The 'ingroup' whom understand the network of names will run the show and anyone who asks what AlphaBetaCharlie actually does, is at an eternal disadvantage.
Judging descriptive names by their worst examples is not exactly a charitable interpretation.
Also an interesting question for company names. Google, Amazon, Apple are whimsical and cryptic. Microsoft hints at software, but is still not very descriptive. Facebook was descriptive, but they switched to Meta, probably to have a less constraining name.
I work in web, and one guy did this for two modules in a non-critical server, just TWO before I flat out told him to stop. "What does X mean" was a common question across people who had actually seen the code before and forgotten, and it was absolutely the first question someone trying to learn the codebase asked. It was a frustrating and silly practice that added to cognitive load and corroded faith in the authors decision-making.
In a team ecosystem where you probably need to optimize for readability and ease of use, try to be simple and accurate and get used to refactoring. Making up random shit is the worst advice I can think of.
I don’t understand why it’s seen as a given that component names can’t be changed. All the given examples are public project names, where there’s a point to be made. For internal components though, where are your refactoring tools?
I give mine “whimsical” names that have alphabetic first letters, and may correspond to positions in a hierarchy.
For example, I tend to use a “layered” approach to servers. In one of my projects, the DB layer is the lowest, and is unnamed (it would start with “A,” if I had named it), so I named the DB connector “BADGER”[0]. The layer above that, is called "CHAMELEON/COBRA" (They are basically at the same logical layer).
I think if you expect you'll only need a small group of people to know the name (the "Shelob" example at a startup), or you expect a large group but only are adding one name to learn ("Vue"), it's fine.
The cute naming gets hard on larger projects. If you have to write a status or design document covering many teams, all with multiple cute names, that document will be impenetrable. It will be as hard as learning a new language - which in a sense it is, because your team will have created a new language that outsiders will need to understand in order to work with your team.
I am on the exact opposite side on this. I always name things after exactly what they do, and I've never had an issue with one of my components taking on a role it wasn't intended for. If the scope changes, that component probably gets wrapped, or replaced, or somehow else room is made for a new properly named component or tool.
This is something I am very grateful for when I return to a project after some time away and the code is documenting itself.
But I'm also a fan of disposable code. If I'm actively working on something I probably rewrite more or less the whole project every 18 months bit by bit.
Here's my rules: if you're writing an API layer for your CustomerTransactions service then name it descriptively. If you're creating a tool to be wielded, name it creatively.
If your software is a "final product" which by definition can grow in requirements then it's best to use a creative name. So if you build a programming language, a build tool, a dependency analyzer, or any kind of software that has the shape of a tool; which the user can wield in a variety of ways. I'm glad we didn't call a hammer a NailPounder since it can do so much more.
Naming is hard. It requires an understanding of what a thing does (or more accurately, at the time of coming up with the name: what the thing WILL do).
One useful practice I've acquired over the years is to make the names unique. It makes it easier to search for them later.
Generally, I would lean towards descriptive names. If the name no longer fits the thing, that's a great warning about scope issues. If it sounds "weird" for other named things to be dependent on or be required by the named thing -- that's often a hint about a context issue.
I remember trying to fix Katello once and trying to figure out why "candlepin" was broken because it couldn't talk to "gutterball". Everything about the situation was terrible.
You could always take the approach of JRR Tolkien: come up with the name first, then try to figure out what the software will do from that name. In a hole in a database, there lived a hobbit.
The biggest issue, I see with learning how software works, is common names.
For example, game engine. Some library or framework, that helps you to build games. Nice.
But what they do for you in detail isn't known, and can take months to understand.
Unity does much more than Phaser. Angular is a total different beast than React.
And this goes down to class names. MVC was the hype back in the days, but nobody knows what it actually meant in detail. Some people sat down and wrote some definition of the term, but no implementer adhered 100% to them.
This satirical video about microservices shows just how deep whimsical project names (and microservice architectures) can go. Displaying the user’s birthdate starts with BINGO (the service that knows everyone’s name-o) and ends with GALACTUS (the all-knowing user service provider aggregator) talking to EKS (Entropy Khaos Service), soon to be EOL’d by OMEGA STAR.
I do like the Intel code names like Tiger Lake, Light Peak and Ivy Ridge. They evoke some kind of combination of Manhattan project megaproject and just-charted territory.
I don't like them - they were OK when talking about 6-8 chips in 3-4 generations. But after the 30th different lake you get thoroughly confused. Apple did it better, switching from big cats to big cliffs after ten releases...
The names are all random and without obvious connection to the product, so does it real matter? The confusion comes from the amount, not the naming. So in this case, calling it an overused naming-scheme might be the better description.
Product family is Core iX, Xeon, Atom, Pentium X etc. Intel® Core™ i9-9900K Processor is a product name.
Lucky you generally only care about release names within a single product because thinking which one is Jasper Lake and which one is Alder Lake is not something I want to do.
Even those product names are not excellent either: Intel introduced i9 which is essentially what i7 used to be and used to justify higher price - look i7 is the same price, but it's the brand new i9, that is totally wouldn't be called i7 5 years ago, that cost more.
I can just about tolerate this for brand names, as there's an additional set of requirements there, but for everything else, it's just gatekeeping and unnecessary obfuscation. If the purpose of something changes, fork it off into something new or just rename it if possible. Apache TinkerPop Gremlin might be fun for the creators, but not for anyone trying to understand what it does.
I called my startup https://text-generator.io despite the name ... it uses image recognition to help generate text and offers an embeddings API, trying to extend it now to generate other forms of content (images, audio etc) depending on the input which is unfortunate
The author subjected themselves to confirmation bias by specifically searching for “despite the name”. Perhaps for every service that outgrew its descriptive name, there were 99 that helped people understand them more easily.
If you were to compare the total time wasted by each category, I’m sure nondescriptive would come out as the most wasteful by far.
What I take from this that across languages, we ought perhaps to have the option, now and then, to use names have two parts: blotwort.django_lint for example. The whimsical part is permanent, the descriptive part is ignored when compiled (has no semantic force) and can be changed as needed without altering how the program executes.
I recommend this book, it was written by top people with decades of experience in creating runtime, OSes, base class libraries, designing APIs, naming and so on
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Addison-Wesley Microsoft Technology Series) 3rd Edition
My 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.
I'd say it gets the worst of both worlds, or maybe even worst of three worlds. It is long, it is cryptic, and it actually leads you down the false path of trying to guess why jeans and why they're blue.
I mean if you go with cryptic then at least call it something short and obviously cryptic. "Chrome" good, "VersatileGopher" bad.
PS Yes I know that Chrome actually has an explanation, but it does not sound like it means something that you could guess if you thought hard enough. I'm also not criticizing Ubuntu release names because the context is obviously different.
By contrast, Jitsi, while totally meaningless, is easy to remember. A whimsical name with no connection whatsoever to the application or library is misleading, a nonce word is better.
I agree that bad and/or misleading names are, well, bad. However, I don't agree that we should just give up and name everything {SomeCrypticNameIThinkIsCool}.
Invest time in naming things well the first time.
Invest time in renaming things to be more accurate when it is feasible.
> CO_Cron: Despite the name, uses node-schedule rather than cron.
That seems like a bad example. I've often googled "cronjob foo" for how to schedule something in foo. Seems like "cronjob" is a general term for scheduling now.
I think cron is short for chronos which is Greek for time. Chronological, chronograph, etc. So a cron job is simply a job that happens at a particular time.
Even in the planning phase, when you have a new project, giving it a name helps in general conversation. It also gives it an exciting mystique and makes it seem like you still give a shit about the job.
are we talking about project names or the names of classes and objects?
if it's projects, ideally the long-term architecture is well enough understood to give the thing a whimsical yet meaningful name (ideally not cryptic). building a page caching service? call it gutenberg or something to start. when it inevitably grows past scope, it's ok. no one will care if gutenberg also handles analytics callbacks or whatever.
classes really shouldn't change in scope, ideally, so it's probably better to be a bit more specific to their purpose.
overall this is a good hot take, if a bit broadly put.
One company in particular I worked for had exotic cute meme names for every big service in our service architecture. Sometimes conceptually related to what it did but often not. Damn annoying!
> If names are too clever, they will be memorable only to people who share the author’s sense of humor, and only as long as these people remember the joke. Will they know what the function named HolyHandGrenade is supposed to do? Sure, it’s cute, but maybe in this case DeleteItems might be a better name. Choose clarity over entertainment value. Cuteness in code often appears in the form of colloquialisms or slang. For example, don’t use the name whack() to mean kill(). Don’t tell little culture-dependent jokes like eatMyShorts() to mean abort().
Stop with the cute cryptic names. If you want descriptive names that can be said with one word consider a good acronym, otherwise just say the whole name.
The choice of using totally novel and cryptic names for everything was intentional. The project is ambitious, and aims to do a completely fresh stack, (OS, drivers, network stack, identity, filesystem, etc.). Given that level of ambition, the choice of names was done remind the user that this is not just Unix and TCP/IP re-written, this is a whole new alien OS, based on distinct ideas.
The fact that Arvo (the kernel) doesn't even have a distinction between RAM and disk, or between PCI input and network input, is a much bigger deal than remembering that "Arvo is the kernel".
OP is right that naming can give a false sense of familiarity, so inverting that for things like this makes sense. Create a false sense of un-familiarity, to keep the users paying attention while they learn what they are using. That's been my experience so far, a heightened sense of awareness while reading through the cryptic documentation.
I'm iffy on this for software (because you can always spin up a separate descriptively-named library to house the "scope creep"), but I'm 100% about this for team names at software companies, for the exact same reason: because you _can't_ easily "spin up" another team to handle the inevitable scope creep.
Let's face it, no software company where any of us work has ever been satisfied with "well, we have enough features already, no need to build more." The incentives _always_ push for-profit software towards "build a shiny new feature", because you can't upsell existing customers the same features they already pay for, but you _can_ upsell them _new_ features.
So companies monotonically grow their featureset.
Companies also do _not_ monotonically grow their employee base, and _certainly_ not at the same rate as they grow their featureset.
So, for example, the "email send team" of today will probably become "the email sending and rendering and link-tracking and some-of-the-reporting-but-not-all-of-it and some-of-the-public-API-but-not-all-of-it" team before long. And they'll probably also gain additional features along the way, some of which are likely to be even _less_ related to things like SMTP and MTAs (which they'll still regularly have to deal with).
In the meantime, those "some-but-not-all" categories will be shared with other teams, usually in a way that's not neatly describable in 1-2 words.
So do you keep constantly changing your "descriptive" team names and fleshing them out into entire often-mutating paragraphs so that they're _actually_ descriptive? Because you're _certainly_ not going to wait to build a feature until there's a new team for it. And what happens when you decide that some of those features should change hands to a different team? Time to go update all your CODEOWNERS files and ACLs and directories and everything so you can change the team's name again?
Or do you accept that memorable-and-unique-but-not-descriptive team names like "Apollo" or "Wombat" are a better use of your time, and find other ways (like relating per-feature PagerDuty "services" to team-level escalation policies) to map "feature X is currently owned by team Y"?
Because honestly? 70% of the time that you would want a "descriptive name" for a team, it's because you're trying to reach/page the right team to fix a problem.
Set up feature/service definitions in your tools of choice (PagerDuty, Jira), and make sure those are many-to-one with the team definitions, and then ensure that those definitions can be easily modified/reparented later.
To put it in programmer-friendly terms, don't use magic strings, factor out real identifier constants, and reference that constant instead of duplicating it.
P.S. to those of you who might say "you can just pick a generally-descriptive-enough name without it listing every feature", I once worked on a team named "<Product> Email Team," and we _frequently_ got questions/tickets/bug-reports about email-related or email-adjacent features that were actually owned by other teams (either on a different product, or as more of a "downstream" thing). We also sometimes _didn't_ get questions passed our way that were related to the non-email features we'd accumulated over time (see also: featureset growth speed vs. "headcount" growth speed). We were eventually renamed "<Product> Email And Content Services Team", ironically because our existing "descriptive" name was deemed "insufficiently descriptive". Rather than fixing the problem, the new name in fact only exacerbates the problem, since no two people can clearly agree on what "Content Services" are.
Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets.
If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing a design up-front, or drawing diagrams of how your system works, then this indicates one of two things about your background.
1. You're a relatively junior engineer who has gotten used to thinking about productivity as slamming code that tweaks existing systems into new incremental features
2. You work on some fucking web service.
Either way, your advice does not apply to the software engineering profession as a whole. Believe it or not, lots and lots of people write software, and not all of it is a web service or some tool / framework to help run your web service. There are many things out there are that can be envisioned, designed in detail, and implemented. And, crucially, in those cases, _it is wise to do so_.
I know I'm being overly dramatic, but it consistently enrages me reading blog posts that, through ignorance or deliberate omission, speak as if the world of software is just writing web services.
Isn't describing this comment as "fulmination" snarky, which is itself a violation of the guidelines? It's at least a shallow dismissal of their opinion, for sure.
How can you expect people to follow these rules when you yourself don't? Looking at your history, you[0] leave[1] comments[2] like[3] this[4] (shallow dismissals at best, and snark at worse) pretty[5] consistently[6]. What gives?
Interpretations inevitably differ, but I don't think those comments come close to matching your descriptions and I can't imagine that most users would either. They seem tediously neutral to me.
Isn’t that the problem? You see your own shallow dismissals as tediously neutral, but others as violations of the guidelines.
For example, in this comment here that I’m replying to, you caveat what you say, and yet you don’t caveat any of the comments I’ve cited as ”your opinion”, despite them being the same value judgements of someone else’s writing.
“Please stop <value judgement of comment>.” Is about as textbook of a “shallow dismissal” as one could get.
You don’t apply the same rules to yourself, so there’s zero reason or incentive to follow those rules for the rest of us.
Edit: Hey, within an hour of writing this comment, I'm now slowbanned (a thing you at one point claimed was removed from HN). So I guess you don't like dissent either, dang?
Edit2: Since I can't respond (you muted me), the community doesn't evaluate your activity objectively; you're worshipped, and aren't give feedback that represents a reflection of your actual behavior, so an appeal to the masses here isn't an effective argument. The community may disagree with you, but it's actively detrimental to say so, and will apparently create negative repercussions for the folks who do speak out, creating a "chilling effect", preventing you from getting the "bloodbath" you apparently think would be necessary for you to change your behavior.
Additionally, the fact that you've made it harder for me to interact on HN as a result of this conversation is an indication that everything I'm suggesting here is even more true than I initially thought.
Users here are extremely quick to push back if we do something they find objectionable. That's in fact how the moderation practices have evolved in the first place—by intense operant conditioning: if you do X and immediately get swarmed by wasps, you're less likely to do X in the future.
Slowbanning and rate limiting are two different things. Your account is rate limited. That's standard practice in a number of cases, including (a) when an account is posting too many low-quality comments too quickly and/or getting involved in flamewars, and/or (b) there's reason to believe that an account is the latest incarnation of a user whom we've banned several times in the past. The bar for moderation penalties is a lot lower when we seem to be dealing with a serial abuser.
Edit: I deleted an earlier response to you because I didn't have time to finish it (I wanted to respond to the bit about 'slowbanning'). If I had seen that you'd already responded to it in your parent comment, I wouldn't have deleted it. The original text was:
We've already established that you interpret those comments very differently than I do. The question then would be: is there any way to
I post that sort of moderation comment all the time—tens of thousands of them by now. If the community agreed with you, we'd never hear the end of it; in fact, it would be a bloodbath. So I don't think the community agrees with you.
> Users here are extremely quick to push back if we do something they find objectionable.
This is simply not true; you act like you're the only person who's been around here for 15 years. There is simply no mechanism to organize any kind of meaningful pushback. Additionally, by virtue of the fact that you already dismiss the people (like me, with your declarative statements about the nature of my comments) who give you this pushback, it's not clear you'd even notice. Just looking at your history I can see a number of folks who fundamentally disagree with how you give feedback, but I guess to you that's not "valid" pushback?
I only feel safe to give you this pushback in the first place because I know your moderation efforts are ineffective to how I prefer to use HN. Otherwise I'd be afraid of getting actioned against, as you aren't a rational actor when it comes to taking actions against users on HN.
Further, you have this habit of making declarative refutory statements such as these without justification or elaboration. That's pretty much the exact definition of "shallow dismissal".
For example, a "serial abuser" might actually just be someone you disagree with who you then take action against as part of that disagreement, but the way you operate is clearly without that possibility in mind.
Edit: What[0] would[1] you[2] call[3] these[4] comments[5], if[6] not[7] pushback[8][9]? Or do these not count because you dislike these users? I'm quite sure, in your mind, you've dismissed these complaints as invalid, and I think that's an error.
Also no, none of these are me. Also also not for nothing but 'tptacek seems to spend an inordinate amount of time defending your work in the form of replies to complaints, and I personally think that's a massive waste of his time, but c'est la vie...
I'm talking about the kind of pushback that happens when we get something seriously wrong and a significant subset of the community gets riled up about it. In the links you've listed, the one example that comes close to that is the pushback against how I moderated the QE thread. In that case I realized I'd made a mistake, and made a bunch of changes. Backing down, acknowledging the mistake, and changing direction is the only thing that works in response to a genuine wave of community dissatisfaction.
I'm not talking about resentful responses from individual users—those are inevitable, if only because misunderstandings are inevitable on the internet, and they don't (necessarily) indicate community discontent. On the contrary, by and large the community downvotes and flags those comments. It's the admins who usually come along and unkill them later.
I'm sure it must be very annoying to be around here for 15 years only to see some random asshole get anointed the big boss of the place and start banning people left and right. But I'm a bit more interested in what people (including you) think I'm doing wrong than you seem to assume.
What annoys me is your continued refusal to acknowledge the unfair lack of recourse available for someone who disagrees with a decision you’ve made, and your flippant attitude around making those decisions when it comes to people you don’t seem to respect.
You’re hiding your behavior behind the mob mentality that punishes dissent, claiming that a shallow dismissal response is valid because the HN mob has attacked with downvotes, so violating your own policies is acceptable.
The fact that I was able to find so many examples in just the past week should concern you. It won’t, because it’s clear you don’t “count” those issues as legitimate, but it should and you should.
“I’m interested in what people think I’m doing wrong.” doesn’t mean you’re interested in improving, however. There are easy, concrete steps you could take; simple rewordings, a policy change or two, that would vastly improve how you interact with the “fringe” of HN.
The very fact that a forum moderator is celebrated like a hero (who never says out loud that there is actually a team in existence), and a guy who called Microsoft dead as a genius next only to gos should tell you all you want to know about the average level of discourse here and quite frankly going against the flow is something I'll have to fault you with at this point since this place is pretty much conformation central.
I can be dismissive of webdevs myself but this comment is too bitter for my taste. It sounds like you learned the salary of your greenhorn webdev nephew recently.
The author did hit on the truth, no matter how he arrived there. Descriptive names are prone to collision, misdirection, and are much too long unless you use acronyms (in which case you may as well come up with a whimsical, pronounceable, unique name and just backronym it). This isn't a new idea. Lots of greybeards know this and name stuff accordingly.
It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more like an ecosystem of organisms that will grow and adapt.
But in OTHER contexts, your software components might be more like organs. If the heart has also become responsible for digestion, then it indicates your system design needs to be revisited. In lots of software projects, this is not an untenable proposition, such as it presumably is in a web service company.
As somebody who works in one of those other contexts, it's important to me that the web service monoculture be correctly contextualized. Otherwise you have people cargo culting it in situations where the wisdom no longer applies. That's probably why I'm being so bitter. :(
I'm saying it's not just webservice monoculture. It predates the web. Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git?
If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothing web-development-specific about that. Big projects get Name-names, like companies or people. Always have.
Maybe we're getting into semantics, but you're listing the names of full software products or outward-facing open-source projects. The world is rarely coordinating to refactor responsibilities between different software products, since now you're talking about trading functionality across company / organization lines. At that level, I'd definitely agree that software is clearly a bazaar, and a whimsical, cryptic name is at its best.
"Software component" has the connotation, to me at least, of being an inward-facing _piece_ of one of these products. It is but one component of a system, and thus it is to be understood by its function within that system.
I think in many domains, the best advice is to name those components helpfully, and to think about the component's role in the system. To start adding functionality to the component outside the scope of its name is to invalidate your design. There is no reason to bloat this component. You'd rather create a new component to handle the previously overlooked role in the system. This is made obvious when you take limiting cases, like designing a moon lander. Here, the software design must be purposeful and optimized, and it only needs to work once. In the opposite case, the component is a web microservice - a living thing managed by a 1-pizza team that always needs to be turned on. Uptime and speed of implementation are at a premium, and creative ways to add new functionality on existing systems are seen as a net good. Here, the article's advice might be good.
Moon landers all get names. Even moon landers that never made it past the design phase probably had codenames.
You've stumbled on yet another situation where you should give something a cute name instead of a descriptive name: If there will be many implementations of the same thing over time. Each generation of Intel processor, each sort algorithm (TimSort, thanks Tim), each rocket, each mid-sized sedan.
Now, do the individual software components within a moon lander get names? That depends! Are they re-used between landers? Are there many different implementations of the same component to choose from for each mission? The more affirmative the answers to these questions, the more likely it is the component will have/should have an actual name, instead of just being, say, "allocator.c".
There are just so many reasons you might want something to have an actual name. Competing implementations or historical implementations, userbase size, project longevity, researchability. And they're all subject to change in the future (and renaming sucks). I have a hard time faulting anybody for giving their little binary data format a name like "parquet", even if it's tiny and only used in one place by one other thing and might never have any users. Because it might end up used for a long time, or by many people, or in a period of competition with another implementation of the same thing. If any of those things comes true, you're going to be glad you didn't name it "Hierarchical Data Format".
I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService, as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus.
Often times when people get creative with names, the meaning dies with them. When they leave the company so too does the reasoning behind the name.
The author conflates service bloat with bad names. Fix the bloat and the name will make sense. If you have an app called “Authorizer” and it does email, you failed. If you have a service called “InfraValidator” all it should be doing is validation. If it’s not (such as tensor flow’s infra validator) then the service/app/codebase is misleading and needs to be renamed after what it does.
I also hate to see overly descriptive names. Package/crate/bundle/module should help classify the name of the class/object/func_collection.
Names like “EnvironmentPostProcessor” (Spring Boot) is succinct enough to know exactly what it does. It processes environment vars after a stage.
In many environments you don't control the evolution of software. Unless the big boss does all the naming, then the people doing the naming can't stop other people from making AuthTokenValidator send change password emails and them eventually send marketing emails. ("Hey, this service already controls the noreply address...")
This is what I'm getting at though. If you work inside a MANGA company or something, then I imagine your life is probably dominated by navigating a huge byzantine ecosystem of services with uptime demands and tons of legacy code. Presumably there's lots of $$ riding on evolving those systems incrementally. In this frothing, roiling context where the only constant is change, I can see how it will often make sense to expand components beyond their original scope. Ergo, your services should be named whimsically. Fine.
But many software projects are. not. that. That's really all I'm getting at. This web service developer bubble annoys me because they never feel any onus to introduce themselves in their blogposts and caveat their opinionated recommendations with the context they're coming from. In my world of robotics, just making a random family of services with non-descript names is a bad idea. The services in the system should have roles, and if the temptation arises to add functionality beyond that role, it probably means you need to step back and do some thinking about why that happened.
Also: I know you were just making a rhetorical point, but notice that your example is still clearly some web service that we're assumed to be running :)
If you developed your services right. You’d have a notification service that does SMS,email,smokesignals…
It’s up to principal/staff engineers to make sure that the components of the system stay lean to its purpose. They should be able to say “oh, we need to send an email when this happens? Here’s an email service we can use” that doesn’t introduce feature creep into AuthTokenValidator.
I get what you’re saying but these little shortcuts (adding email sending in AuthTokenValidator) cause enormous tech debt later on when you scale.
>Often times when people get creative with names, the meaning dies with them
That's fine though. Anything you work on will inevitably develop a personality in your mind beyond what the name literally means, so what's the difference if the name is something like GAS (generic-acronym-service) or Fuel (GAS > gasoline > fuel).
A persuasive dev at my last job tried to insist on non-acronym names for every new service, and 5 years on, I can still remember every proper name, but none of the acronyms. That, to me, is sign of a good name.
> The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming
I'd assume everyone here could at least agree that naming is hard. I don't think the article was attempting to explain how to name, but instead point out one potential pitfall when naming.
This, exactly. Seemingly misnamed services are a sign of architectural decay. That sign is useful if you pay attention to it. If it's embarrassing to explain to new hires, just fix it!
What bothers me about this comment is that it’s a roundabout ad-hominem rebuttal to the author’s argument. Reading the essay, I have no reason to believe the author has only ever worked on web services. But I would if I was angry and trying to discredit the author.
The author actually does discuss the nuance. They argue exactly your point saying that their “considered harmful” advice only applies in situations where the scope of the component is ambiguous/fluid/unknown/otherwise prone to change over time/etc. In cases where you have a mature fixed design, choose an appropriately descriptive name.
I’m glad you have only ever worked on projects that were perfectly designed up front. Sounds like the dream. For the rest of us, we engineer in reality. And I find the author’s point apropos.
> you are doing a bad job of producing an up-front system design
Or, it could be that you're actually innovating and requirements are changing faster than you write code.
A late change in requirements is a competitive advantage.
There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.
This strikes me as a false dichotomy. The choices aren't limited to "BDUF" OR "NDUF" (No Design Up Front). There's a continuum along which the amount of up-front design that is required can range. I prefer the term SDUF (Sufficient Design Up Front). And of course we all have to keep in mind that design and architecture aren't things that only happen "up front". Design and architecture work-streams should continue throughout the lifecycle of the project, IMO. The relative weighting of the different work-streams can vary, but the key is that it doesn't just end after the first (iteration|sprint|phase|whatever-you-call-it).
SDUF and redesign as necessary is where my job mostly falls. If we're facing an unreasonable deadline, "redesign as necessary" can turn into "just hack it in" though, which is what I'm currently dealing with.
I have nothing against undescriptive product names. But if you are constantly changing the entire problem your software is intended to solve, you have a problem.
And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.
Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too.
Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.
> Real world problems can change very quickly and as such, software changes too.
So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.)
The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.
The tone of your post is unnecessary and not helpful to your point. I don't agree with the authors point but I can say that without being insulting or snarky.
In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...
On the contrary, I assume making decentralized database products is very hard. And I don't doubt that authorization is a whole can of worms. My point is not that they're easy, but that they're the type of problems you are most likely to care about if you're building a web service.
A web service. Not a moon rocket, or an MRI machine, or high frequency trading software, or computation fluid dynamics simulations, or a compiler, or a video processing pipeline, or a word processor, or a 3D game engine.
So, just saying: When bloggers consider the headline "Software component names should be whimsical", I wish they'd spend a second to ask themselves whether their advice actually applies to any of the niche domains I mentioned, or if it's just a best practice for their fellow web service developers. Presently, there's a cultural trend that you don't have to bother with that step, and you can just write as if your audience is always the other web service people in the valley. To me, that gets very grating, and that's where the snark comes from.
Asking the author to provide more context on what domain(s) their blog post is meant to apply to is a reasonable critique.
However, consider whether your original post made that critique clear, or if it got lost amidst the other ... stuff. The first two lines, in particular, will immediately put some readers (myself included) on the defensive. Describing somebody's work as "some web service bs" is a bad start. And if your point had nothing to do with the "hardness" of the problems, only that those particular problems are most relevant to building web services, why not just say that? Instead of the "...somebody who works on some web service bs assumes that that's as hard as the world gets," bit.
When it comes to rockets, whimsical names seem to be much more popular. Most of them are named after mythical figures with SLS being a notable exception.
We don't need no security. Just here to remark that I quite like the tone of GP even though I kinda fail to see the point being made. Fuck what Web services have become and fuck the people who piled all this accidental complexity on top of what was essentially a very elegant kind of software, and could've remained one
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.
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 of three internal 2.0 rewrite projects is called that) or Venice (because it’s a place that has lots of hotels).
As part of their ambitious rewrite, they also start building a custom message queue in XYZ. It’s called Milan so there’s now a cute city theme. A bunch of other exciting NIH XYZ greenfield projects spring up, all with city code names.
Another ten years go by. A programmer complains to another:
“Where I work is the worst. There’s all these projects written in XYZ which nobody uses any more, and they’re all named after random cities. Why couldn’t they call the hotel booking service something descriptive.”
How about just Hotels 2.X.X.X? Honestly, not much reason it can't be the exact same namespace depending on the language and whether the new and old would be imported by the same project.
If someone doesn't like something, they may criticize anything about the thing, such as (a) having or a silly name or (b) having a generic descriptive name. Sometimes you just can't win. Sometimes such 'spillover' criticism is better understood as collateral damage from deeper frustrations.
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. :)
This is the right middle ground imo as well. It adds a bit of simple difference between the 15 different exporters, without being too far off. We have things like the "Tenant Saw" - extracts a tenant from a multi tenant system, or a foosystem-butler called Vlad - automating and scripting a bunch of busywork around the foosystem.
> Cryptic names are horrible. It's a layer of cognitive overhead that no one needs
I disagree with that. Cryptic names can become jargon, and jargon is useful in expert teams. At my last job we had a service whose role was to convert operations from system A to system B so at first we named it systemAOperationsToSystemBOperations. The name was clear but it was a pain in the ass to talk about it. We renamed it adios as a shorter name (irks like a fake acronym of the initial name) and it became way easier to talk and reason about our system. We lose a few minutes once in a while to remind juniors what adios does but we gain an efficient name to discuss the service day to day.
It says "component". How many components do you have? I suppose if need to deal with more than a dozen components simultaneously, something is wrong. What is worse, the overhead of maybe not knowing a one-word description of component FancyName once in a while (so you have to look it up, pressing F12 or such), or having to deal with a obsolete, too long name (trying to be clear, or having too disambiguate between multiple redesigns), or unfitting name: all the time you're working with the thing?
Screens are huge now. You can fit long names. Auto complete makes typing long names easy. Let your code read like prose. Save the brain for solving the business problems not for understanding the code.
Long names are easier to read the first time, and become an impediment thereafter. Especially when you have multiple long names that differ only in a few characters.
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.
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.