5 ms·

Unrelated meta-side-rant: this leak exhibits one of the two types of naming conventions for internal tools that I really dislike: - Unrelated historical/comic

Unrelated meta-side-rant: this leak exhibits one of the two types of naming conventions for internal tools that I really dislike: - Unrelated historical/comic book/movie references, e.g. "Project Morpheus" or "X-37" or "Calligua", "Wolverine Project" etc etc. Meaningless. - Things like this Nissan leak where everything is an acronym that is meaningless on its own. TTBA. SSKLR. URA. PIIY. What the hell? Both are awful. Please please please if you are responsible for naming something at your work, please choose something descriptive. E.g. instead of picking something "clever" or "cool" like "Boudicca Project" or "Skylark" or some useless acronym like "CTITT" please call your mundane CRM system something meaningful like "Customer Management Tools" or something understandable without knowing the backstory (e.g. "we called it Team Sofa because it replaced and old CouchDB instance, and everyone used to hangout on our sofa in our office when we did meetings - duh") and easily searchable. Future users and engineers trying to figure things out will thank you.

adenadel 6y ago
I think you make really good points, but I thought that the main reason for using internal names like you describe are so that if the names aren't recognizable if they are used indiscreetly (i.e. to protect projects that are in development from being leaked inadvertently).
- davidrm 6y ago
  OEMs use codenames because they're often sending/receiving parts to/from external suppliers, e.g. when driveshafts go around random warehouses and logistics companies they have the codenames on the boxes and stickers. they impose the same rules on tier 1 suppliers in order to maintain secrecy and streamline communication, that way everyone is referring to the same project using the same naming convention while preventing incidental leaks
- stretchcat 6y ago
  This is how battle tanks came to be known as 'tanks'. At the time, any german spy who overheard the wrong conversation would think the British were talking about containers for holding water.
deleted 6y ago
[deleted]
chenxiaolong 6y ago
100% agreed in general. In this particular case, that's likely the Bitbucket project name (or "slug" if you're looking at the API or backend database). On our old instance at work, it's all caps and has a short length limit, at least by default.
ajsnigrutin 6y ago
"dude, just name the project something, it doesn't matter, we'll change the name if it get accepted" (been there, done that a few times.... there's nothing more permanent as a temporary solution)
gretch 6y ago
I disagree with this, here's why: 1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Customer Management Tools" - ultimately there's a whole host of things all over the stack that could be considered "Customer Management Tools". Some words even come with organizational _baggage_ where stakeholders immediately think "ah we've been waiting on this for years" and you have to explain, "no this doesn't do that at all" 2. Software can change in functionality or sometimes even purpose over the course of it's life time (let's say 2-4 years, or longer). While the name is typically easy to change in user facing parts of the product, repository names and URIs are the harder parts and typically get cemented after creation. If you combine points 1 and 2, you get something that's worse than wrong or cryptic - you can get naming that is actively misleading I've seen real examples where someone started a project called "promo renderer". 3 years later new ppl onboarding onto the project will say "this renders promos? where's the code that shows the promos?" and the answer will be "well this doesn't technically render the promos, it's a configuration system which helps decides which promos get rendered; the actual render is another system". Unfortunately, it was almost impossible for the day 1 dev to see that level of nuance/precision. My final argument is not necessarily that detached names are better, but there are definitely sharp downsides which I've felt that you have not considered.
tonoto 6y ago
While future "users and engineers" might be thankful, other stakeholders might not. Project names serve a purpose of secrecy in situations where you have classified information or trade secrets and somehow end up in situations where you need to communicate about it out in the public. Security by obscurity that is rather discreet but effective.
0dmethz 6y ago
You kind of have a point, but "Customer Management Tools" sounds like it could be absolutely anything. If that's the alternative I'd rather have a fun memorable name.
blacksmith_tb 6y ago
Isn't this a problem between naming for the purposes of project management (where a unique, even silly name may be a plus) and project maintenance (where, like you say, it's opaque and confusing)? I tend to err on the side of maintenance, since you only launch it once, but you have to live with it for a lot longer, but I can understand the impulse to label the project itself - it just needs to go away or be in some other channel from the get-go.
throwaway889900 6y ago
Acronyms are absolutely meaningful and descriptive usually, you just don't have the context. They're used and abused in corporations for exactly this sort of situation. If you have access to the source but not any context, it becomes increasingly difficult to copy what something is actually doing.

adenadel 6y ago

I think you make really good points, but I thought that the main reason for using internal names like you describe are so that if the names aren't recognizable if they are used indiscreetly (i.e. to protect projects that are in development from being leaked inadvertently).

davidrm 6y ago
OEMs use codenames because they're often sending/receiving parts to/from external suppliers, e.g. when driveshafts go around random warehouses and logistics companies they have the codenames on the boxes and stickers. they impose the same rules on tier 1 suppliers in order to maintain secrecy and streamline communication, that way everyone is referring to the same project using the same naming convention while preventing incidental leaks
stretchcat 6y ago
This is how battle tanks came to be known as 'tanks'. At the time, any german spy who overheard the wrong conversation would think the British were talking about containers for holding water.

deleted 6y ago

[deleted]

chenxiaolong 6y ago

100% agreed in general. In this particular case, that's likely the Bitbucket project name (or "slug" if you're looking at the API or backend database). On our old instance at work, it's all caps and has a short length limit, at least by default.

ajsnigrutin 6y ago

"dude, just name the project something, it doesn't matter, we'll change the name if it get accepted" (been there, done that a few times.... there's nothing more permanent as a temporary solution)

gretch 6y ago

I disagree with this, here's why: 1. If you try to make the name descriptive, it could possibly be accurate, but lack precision. To take on your example "Customer Management Tools" - ultimately there's a whole host of things all over the stack that could be considered "Customer Management Tools". Some words even come with organizational _baggage_ where stakeholders immediately think "ah we've been waiting on this for years" and you have to explain, "no this doesn't do that at all" 2. Software can change in functionality or sometimes even purpose over the course of it's life time (let's say 2-4 years, or longer). While the name is typically easy to change in user facing parts of the product, repository names and URIs are the harder parts and typically get cemented after creation. If you combine points 1 and 2, you get something that's worse than wrong or cryptic - you can get naming that is actively misleading I've seen real examples where someone started a project called "promo renderer". 3 years later new ppl onboarding onto the project will say "this renders promos? where's the code that shows the promos?" and the answer will be "well this doesn't technically render the promos, it's a configuration system which helps decides which promos get rendered; the actual render is another system". Unfortunately, it was almost impossible for the day 1 dev to see that level of nuance/precision. My final argument is not necessarily that detached names are better, but there are definitely sharp downsides which I've felt that you have not considered.

tonoto 6y ago

While future "users and engineers" might be thankful, other stakeholders might not. Project names serve a purpose of secrecy in situations where you have classified information or trade secrets and somehow end up in situations where you need to communicate about it out in the public. Security by obscurity that is rather discreet but effective.

0dmethz 6y ago

You kind of have a point, but "Customer Management Tools" sounds like it could be absolutely anything. If that's the alternative I'd rather have a fun memorable name.

blacksmith_tb 6y ago

Isn't this a problem between naming for the purposes of project management (where a unique, even silly name may be a plus) and project maintenance (where, like you say, it's opaque and confusing)? I tend to err on the side of maintenance, since you only launch it once, but you have to live with it for a lot longer, but I can understand the impulse to label the project itself - it just needs to go away or be in some other channel from the get-go.

throwaway889900 6y ago

Acronyms are absolutely meaningful and descriptive usually, you just don't have the context. They're used and abused in corporations for exactly this sort of situation. If you have access to the source but not any context, it becomes increasingly difficult to copy what something is actually doing.