Pretty much every CPU has some internal code name before it is released to the public (and even after it hangs on). But what about software projects? Are those usually code named? Do you code name your projects?
closed as not constructive by Yannis Rizos♦ Jun 19 '12 at 16:02
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
Yes. We are not sure what we are going to call the project/app we are working on at the mimute so we came up with a quick code name so we didn't waste time thinking about a name when it isn't strictly relevant. |
|||||
|
|
Never. All of our applications support some part of the company's business and by the time the project gets to us, the name is already established. |
|||||
|
|
Let's put it this way: Sometimes, you have no idea what you're going to call your project in the end. So until then, what do you call it? Other times, you know exactly what your project is going to be called. So, what else would you call it? |
|||
|
|
|
Beware of code names. They will escape into the public domain. So if you already have a product/project name use that from day one. If you don't have one think long and hard about the name before choosing one. For software projects that produce a product the early name can and will live on in the code base long after it's been replaced by the real name. The name affects so many things - executable name, namespaces, class names even methods and variables - so if you change the name it will have all sorts of knock on effects in the code base. |
|||||||||
|
|
Codenames are useful as a level of abstraction between the source code and the product. Your code repository needs a name. Classes or configurations will need a name. Once set in code these are quite cumbersome to change. Unless your product is well established, its public marketing name is likely to change. If your product is well established, then the public-facing product might split into multiple products which rely on the same source base. Having a codename avoids confusion in all these cases because the codename refers to the source, not the product. That said, I avoid codenames that are difficult to remember. I prefer names which include some plain descriptive element that make it clear what part of the product they refer to. Unless you're working on something so super secret that even the name is valuable IP (let's be honest, very few of us really are) then having an obscure name just puts up a wall between those who understand what it means and everybody else in the company. |
|||
|
|
|
We used code names at Sun Microsystems, for both software and hardware projects. The justification was that you can go have lunch with coworkers and talk about different projects, and someone listening in wouldn't have an idea of what you were talking about. Code names are also nicer because they are shorter. It's easier to say "Hammerhead" than "the next generation unnamed Sun Enterprise E10000 server" (not the real code name). For ClusterTools, we used a shark name theme for each release, and at each release we'd have t-shirts or hats or beer labels with a picture of the shark. It was a nice way to do some team bonding. Also, coming up with the list of names and themes is fun for the group too. As a researcher now, I probably should use code names for projects. Instead, I refer to each unit of research by the name of the target conference. But saying "that ICSE paper" isn't good if you need to submit to a different conference (upon rejection or if you think it's not yet ready), and then you have to rename your latex files and directories. |
|||
|
|
|
Yes, all my projects do have some kind of codename. For some reason I find it fairly easy and logical to come up with a completely dumb name for my projects. |
|||
|
|
|
No, but I did try to persuade my Boss that we should start such a practice based on woodland creatures. Mainly due to wanting to have conversations with the Directors about project Badger and Squirrel... or if it was a project we didn't like... Woodlouse. :) I was honest about my reasons to the Boss but he didn't buy it... :( |
|||
|
|
|
We have internal names for our products but eventually our product managers decide on a cool sounding name. |
|||
|
|
|
Problem:
Solution: Come up alternative TLAs to use as code names
|
|||
|
|
|
You are best to use Pokemon names. As every year a new 150 names will be in your name library for consumption. http://en.wikipedia.org/wiki/List_of_Pok%C3%A9mon This methodology also allows your project to evolve! |
|||||
|
|
Our internal products like test tools, all have cool names. Our main products (the ones that are sold to customers) have an internal code name which is never exposed out. For customers, the product name fits a series like Product1000 Product5000 indicating relative capability. |
|||
|
|
|
Only one company I worked for did that. And that was for internal apps. Most of them out of one department had gemstones as code names:
My project's code name was |
|||
|
|
|
At my last job (not the one mentioned in my other answer), we referred to a major version with the following Ubuntu-inspired naming convention: [sickly condition] [alliterative animal name] Which gave such names as "Limp Lamprey", "Wounded Wombat" and "Asthmatic Anteater". |
|||
|
|
|
I didn't want to figure a name for my last project since I was new around and didn't want to impose anything on anyone. I named it "ProjectX" until someone figures a new name. Now it has been 4 - 5 months and it's still projectX. Next time I'll name it something offensive so people will try to figure a new name fast. |
|||
|
|
|
We used a code name for a larger project, mostly because it was totally unclear what the name would be when we started it and you definitely need something to call what you're working on. We also used code names for release versions, although these never got out to the customer, unlike Android's and Apple's code names used to these days. My last company had a habit of naming projects with something more or less arbitrary. Maybe there was some meaning behind the code name choice, but if there were I hardly ever got it. |
|||
|
|

