Why I don't like project code names

Lately we've been in the habit of assigning code names to projects my team is working on. We have "Sterling", "Caprice", "Janus", etc. The list goes on to include "Bentley", "Moonstrike", "Delgado", "Kodiak", "Donnybrook", and others.

This is similar to how Microsoft typically uses code names for products before they have chosen an "official" release name. However, we're doing it even in cases where the products already have a name!

Here's why I don't like the code names:

1. They confuse users. In discussions with users and stakeholders, they often don't understand why we keep calling the product "Sterling" rather than "EscrowManagement" or "EMS", for example.
2. They make it hard for developers to find things. In SourceSafe, OnTime, and SharePoint, I see a proliferation of strange words. How am I to know to look for "Caprice" when I want to find the source code for the Standards Management System?
3. They make it hard for DBAs to associate databases to projects. In several cases, we've actually named the database after the code name in test and production. How are the DBAs to know what application the Janus database goes with? Resolving this and item 2 above require the use of a lookup step to map code names to their project.
4. They are geeky. These sorts of things appeal more to developers than to users or executives and create alienation.
5. They lead to inconsistencies that have to later be found and corrected. It is tempting to use code names on screen and report output, but in the final release, that's not going to fly, so someone will be busy going through all the source code to make sure all those references use the real product name before final release.
6. They serve no real purpose. Code names add a level of abstraction, and in most cases that just makes things harder to manage and understand. In the cases where a name is needed for a project before it has an "official" one, just do your best to pick something that is likely to be an acceptable final name. It will be more meaningful than a code name.
7. They create separations in the chain of knowledge about a project. Typically, we assign a different code name to each new version of a project. The result is that when you want to search for information across the lifespan of all versions of the product, you have to search an array of code names.

I would be happy to see project code names go away. If an official name hasn't been chosen, do your best to pick something meaningful. And if you must use a code name, rename everything to the real name once it's chosen.