Comment by mattlondon | Hacker News Reader

Comment by mattlondon | Hacker News Reader

Parent Full thread

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.

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.

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).

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.

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

"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)

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.

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.

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.

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.

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.

Reply on news.ycombinator.com