Naming convention for new projects

Question

I've tried several times to come with an answer to this question. I'm not happy with how projects are named in my shop, they are usually random named after some of these items:

• the client
• some technology used/ or expected to be used inside the project
• some acronyms for the business case the project would relate to
• some names from the domain the project would be in

I find several drawbacks with those approaches:

• the word pool quickly dries up when you have many similar projects
• having the client name inside the project makes it harder to have it abstracted to a generic product
• the acronyms usually sound horrific
• there are many projects that would not pass the prototype phase, and because of this they don't get a proper name
• it's hard to name a project before you know exactly what it does, so most of the time the name picked for the svn and issue tracking project are bad ones.

Please tell me:

What is your naming convention in your shop, are you happy with it, and what would you choose if it were up to you?

Thank you!

Answer 1

One approach woth considering is the "codename" approach - give your projects internal codenames that have less to do with what the project is about, but sound better. This will make your own work easier. When you a release is coming near, have the marketing department come up with a "real" name.

This of course means that the "real" name has to be configurable in the project from day one, so that in the end you can just change one line and recompile.

This is similar to Vicky's approach. Many large companies seem to follow this too (like Microsoft).

Answer 2

We allocate a project number (P and then five digits) which is how the SVN, issue tracking, and document repositories are named; then the project has an informal name which is normally some humorous anagram or phrase arrived at by word association from the client name, what the project is for, etc.

This means that the names are hidden from the client (we just refer to the project number) but we have an easier way to refer to it internally that doesn't involve everyone remembering which project has which number!

There's usually an email round to the project team to get names suggested near the beginning, and the best suggestion is picked.

Some of my favourites included two Base Station projects which were named "Taoist Beans" and "Bonsai Teats".

Answer 3

i usually devide my projects per client since we have multiple projects per client sometimes, but never do we use the name of that customer inside the naming of the project.

therefore with your wordlist you will only run dry per client. and you need a lot of projects for 1 client in order to run dry that fast.

so customer x can have a businesscardgenerator tool, as can customer y and usually for customer y we start from the tool used by customer x and throw in a whole new template. add some custom fields and properties if not possible then we of course have to start over.

so in general we have a folderstructure for the names you mention and then the project name is actually a very short description of what the project does OR, the project name is the actual project name that the client intends to give to the site/tool/... though we are currently using the first for new projects, we still have left-over projects from before we implemented this use.

intern/projectX/doc
intern/projectX/resources
intern/projectX/media
intern/projectX/code

extern/clientX/projectY/doc
extern/clientX/projectY/resources
extern/clientX/projectY/media
extern/clientX/projectY/code

Answer 4

I've no convention, usually project name is a contraction of customername and a contracted description of the project like "matforming" or "bottlemeasurer". Sometimes if we work for multiple departments or project groups at that customer we extra qualify it with department.

That leads a bit to the same problem (first project often gets the "client" name without department qualification), but IMHO that can't be avoided. Fiddling out the company structure of a new client while only doing a prospect is a bridge to far.

Sometimes the descriptions are also a problem, when you start developing variants on an existing product, or second generations. But that is also quite difficult to predict.

Answer 5

I've been pondering this myself for the past few nights for my Subversion repository setup. What about this. I helped to start a small computer shop which led me to the coding, so this is based more on experience than logic. You all should already have a unique ID for your clients for records anyway, so leverage that. Dedicate 000000 or equivalent to in-house software or official releases for sale. All other numbers will be for a custom job from the corresponding client, like websites. I should clarify... below is the directory structure. Hope this helps. :)

000000 - (Client# always belongs to: Inhouse)
    <In-House Project1: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <In-House Project2: Codename/Release Name>
        <Files> (Trunk, Branch, Tags, etc.)
000001 - (Client# belongs to: John Doe in NC according to records.)
    <One of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
{...}
002731 - (Client# belongs to: John Doe in LA according to records.)
    <One of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)
    <Another of John's Projects: Sensible Name>
        <Files> (Trunk, Branch, Tags, etc.)

Answer 6

I am in favour of the "codename-approach" but with added emphasis on including functionality and wittyness. Both for making it easy to remember what the project is about.

And then create additional hierarchical structures that sort by logic relations like "customer", "year", and such. You may want to introduce either some standard procedures for project creation or (considering that you are in the automation business) some automation.

(It might be that there are already systems existing out there to do so, I remember some presentation related to some envisioned filesystem in Longhorn that I attended years ago.)