
Ask HN: Codenames for proejcts? - cryptozeus
Our company culture is such that all the software project names are very &quot;boring&quot;. I am trying to change that and would love to have better internal product names.<p>I can&#x27;t find a good argument to achieve this. For example it would be fun to refer to our testing framework as &quot;kraken&quot; instead of &quot;Tester&quot;<p>how do you decide your project names ?
======
ohjeez
Well, you do want them memorable to the people in-house but obscure to
outsiders (such as anyone sitting at the next table in the coffee shop).

Back in the day, the much-waited-for Version 3 of Lotus 1-2-3 was called
Godiva. (Just because everyone liked the chocolate, I think.) But Lotus knew
that a lot of customers wouldn't own the high-end computer that the new
version would require (hoo-boy a 386!), so they also created Lotus 1-2-3
version 2.2. That was far less sexy of a project to work on, so its code name
was Chunky (after the much cheaper chocolate candy).

At the same time, Lotus worked on a SQL database that never _did_ see the
light of day. Its lead designer was one of the original 1-2-3 programmers,
who'd gotten tired of people asking him what he was working on next. So the
code name for our project was, "No comment." Then when he responded, "No
comment" to "What are you working on?" he was being explicitly correct. (...I
still have the polo shirts and other swag from that project, too. Cool logo of
/* */ )

------
_ah
I HATE clever names. Clever names are fun. They tickle that little corner of
the developer brain that delights in obscure trivia, and makes everyone smile
and nod and pat themselves on the back as they celebrate their cleverness.

Fast-forward 2 years, and no one can remember what thing does what.

1\. New devs on the team have to learn a long list of acronyms and code names,
slowing down their ramp-up.

2\. Trying to find information is nearly impossible, since you can't just
keyword-search for "test" and see all the related dependencies, but instead
have to reference some internal code sheet.

3\. Duplicate work often results, since you can't easily see the thing you did
last time, and if you forget where you put it you'll never find it again.
"Wait, is this Kraken? Or was that supposed to be Ahab? Is Nemo the search
indexing service or was that Marlin?"

In my teams, I've always dictated boring but descriptive project naming, along
with a nice README that includes a description of what the thing does, why it
exists, and a handy list of keywords in case you try to find this information
later. BTW this also works well for class names, variable names, etc.

Or you could, you know, do something fun and not boring. And have all the
developers who come after you curse your name.

~~~
cryptozeus
humm good points. I will go and do something fun YOLO

