How do people handle working with Code Names for their projects?

Question

Hi All,

Recently we started using some code names for several different types of prototype applications all following a theme. This made things a little more fun and was a great idea.

The problem is that Im not too sure how people deal with migrating a codebase from "codename" state into version 1.0 state which may have a proper name... not something that a client really shouldnt see :)

We are using Visual Studio at the moment, and I can see that you can change the assembly name, but there are references to the namespaces, etc... that would really be a large change to make.

Do people bother changing things like namespaces before the v1.0 release?

Answer 1

I prefer to change all references including project names, folders, namespaces, everything whenever the real name changes. It can be a bit of a pain, but it's better in the long run, especially when new developers are introduced to a project and are not familiar with the history.

Some companies continue to use code names internally even after the real name is decided and released. Even today there are some places where "Opus" shows up in reference to Microsoft Word (when digging into window handle info, not any published api or ui).

If you keep code names around, you end up with a mess and a large document to have to know what is what.

http://en.wikipedia.org/wiki/List_of_Microsoft_codenames

Answer 2

I've always considered development names to live in a different space than the deliverable product name. Unless the development name is profane, or you are producing libraries or APIs, I don't see necessary harm from the development name appearing in a symbol table or sumptin'. (Your customers will generate their own profanities for your code, anyway ;)

Sam's answer sort of agrees with this stance, if the development names never got outside the code pit, there wouldn't be a Wikipedia page listing them.