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).
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).
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.
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 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.
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.
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.
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.
> 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.
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.
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!
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.
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.
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. :)
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.
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.
> 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.
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.
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.
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.
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.
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.
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 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 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).
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.
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.
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.
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.
> 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.
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.
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.
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 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.
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 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.
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.
338 comments
[ 6.3 ms ] story [ 341 ms ] threadWhoever 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.)
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).
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).
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.
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.
[1]: or rather, if they were longer, the first 8 had to be unique.
After all hackers were always - by and large - weebs, with their fascination with martial arts and Japanese culture.
Compare: "Nile Online Frameworks"
No simple name can describe the job 100% after a certain level of complexity anyway.
Those are synonyms. What is your point?
I mean it could’ve been “RedHat Cthulu” and “Amazon RainBox”.
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.
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.
[1]: https://xero.com
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.
There's probably some cultural context I'm missing here, but I asked around in the office and got a different answer each time as to why it would be named like that.
That was 9 years ago and I still don't know BTW.
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.
A tool for sending mails via Mailgun? “Railgun” then, for example.
Banana Cache
Hadouken Security Service
Lightfoot Containers
I mean, this is pretty much the AWS formula.
I'll keep this formula in mind too, and use it when I develop something bigger.
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.”
Descriptive alone does not cut it.
Bonsupoints if your software throws errors, that throw customers. "I want to book a flight to NY, but it keeps saying Venice:DB is full"
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.
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.
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 ?
Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?
Some of you are thinking, well, what if you need to interface with facebook dot com? Easy, I'd call it the SneedFeed. If you know you know.
Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
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.
> 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.
That way, they're both whimsical but easy to remember, and if they drift a bit, it's fine.
"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.
"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
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.
The name itself comes from Dune, where the Bene Gesseret Missionaria Protectiva is itself whimsical (on some level) and cryptic. https://dune.fandom.com/wiki/Missionaria_Protectiva
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).
[0] https://littlegreenviper.com/miscellany/forensic-design-docu...
Judging descriptive names by their worst examples is not exactly a charitable interpretation.
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.
[1] https://kevincox.ca/2021/03/23/good-names/
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.
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.
Very bizarre ... also, why not BOTH a diagram and discription.
The original escape turned out to have character issues or so, so they made a new one: mysql_real_escape_string
We were hoping they would find another issue and release a mysql_real_real_escape_string
My team work on a project with many "funny" names, including but not limited to, liboyster, libowl, several characters from Fort Boyard (https://en.m.wikipedia.org/wiki/Fort_Boyard_(game_show), patric the starfish....
It was awful to work with, please don't go that.
Probably hard to get street cred for a cutting-edge processing monster named FluffyKitten.
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 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.