I think using codenames are quite widespread. Our company is using them too.

But my main concern is these names are usually not documented anywhere. And the meaning is spread by the word of mouth. And the names have nothing to do with function of the tool or entity it's named.

I see the pattern that the internal test machines are named after constellations, Public facing servers are named after Greek gods. And projects are named after places or the name of some randomly chosen film star or character name. But no information directly available from the name whether the machines are Windows or Linux; 32 or 64 bit servers. Or what's the project about.

I just have a bad gut feeling when I see the commit message of the VCS that someone just branched the "Gandalf" project or the "Callanish" project or whatever project. Just for the same reason, you generally don't name your functions and variables like that.

I proposed that we should use more descriptive names, at least for the new entities, but I faced very strong opposition. Apparently everyone in the organization except me love naming stuff like that.

So why do we use non-descriptive codenames?

Don't get me wrong I have no problems naming program versions and milestones, or having a nice product name for marketing reasons. But all other places I would better like to see descriptive names.


To give you some context: Gandalf is project that ports the code 64 bit. Callanish is which ports it to Android... I'd rather call the former branch 64bitporting and the latter androidporting. Maybe a suffix attached to it denoting the target version we plan to ship it. So everyone would know by name what it is.

The servers in question are virtual machine images we test the product on... I don't know the physical machine it actually runs on though. So calling them windowsxp_32, windows7_64, debian_32 or solaris_64 is totally fine.

closed as primarily opinion-based by gnat, Mike Partridge, Blrfl, Dan Pichelman, user40980 Nov 6 '14 at 18:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    What is descriptive to you might not be descriptive (or consise) enough for someone else. A name is a name is a name. No confusion or disagreement. – Robbie Dee Nov 6 '14 at 12:28
  • 1
    So many answers, and yet, if you ask the question "Should I be naming my servers by purpose or by greek gods?", I suspect/hope purpose will be advised. And yes, fileserver4 is easier to remember than Aphrodita, when it comes to remembering which are the servers with ftp. – Vorac Nov 6 '14 at 13:47
  • 2
    This question appears to be off-topic because it is unrelated to software development. – Mike Partridge Nov 6 '14 at 15:09
  • 4
    What’s in a name? That which we call a rose by any other word would smell as sweet. – Caleb Nov 6 '14 at 15:19
  • 3
    I hope the Gandalf branch isn't the codename for a unit testing framework. Anything run through it SHALL NOT PASS! – corsiKa Nov 6 '14 at 17:45

10 Answers 10


We don't reference people by their characteristics as it takes all day to list them in enough detail to be unambiguous and the characteristics can change. What if they get a haircut? Instead we give them names. Also, people are better at remembering words than streams of random symbols.

Disclaimer: This is going to contain some opinion and anecdotal tales due to the question.

In a place I worked a couple of years ago, all our servers were named after moons and body parts. "Rhea","Miranda", "lung", "kidney" etc.

Up high decided, like you, that this was all a bit silly and we should change them to more "descriptive" names like "arc-sql-w-4" or "lon-web-lin-2". This was met with much opposition. But it went through. We renamed everything.

So what went wrong?

Previously, we'd know off the top of our heads which machines were the primary databases and which were the slaves because we could remember "heart" controlled "head" or that "Tarvos" was an application server for X. Whatever. Now we had to remember an obscure pile of symbols that partially, but not fully described the machine we were looking for. We had to know via some lookup table in our heads that "lon-web-lin-1" was an application server for product A and "lon-web-lin-2" for product B.

It's similar to the reasons you should use passwords like FartDownTrousersForALivingDoYou? instead of 43gH5#€1. People are good at remembering words, not random piles of junk. Words are symbols that refer to things.

Another (arguably more practical) problem is that you're tying your DNS and server names to their functions. Which means you can't change the function without changing the name. For us this included physical location and operating system too. Which is a massive pain in the arse.

Also, and this is the last point. Names are far more fun.

What about project names?

Well, instead of "Project Gandalf" what do you propose? "Project prototype function X and see if we can evolve it into a product"? What if the project scope changes, do we then rename the project? Again, names are shorthand symbols that refer to things.

  • 4
    Seems like you changed descriptive metaphors for non-descriptive hieroglyphs. You should have enforced a naming pattern that makes clear which product runs on which server. That's what being "descriptive" is about ;) – back2dos Nov 6 '14 at 12:09
  • 8
    @back2dos - And when a new application gets deployed to the server or an existing application moves to a different server, do you rename all the affected servers? What about when Product A gets renamed (since we're not using code names)? Are you going to change everywhere that name is stored on a client? Or are you going to leave misleading DNS aliases in place to minimize the scope of the change? – Justin Cave Nov 6 '14 at 12:23
  • 4
    @back2dos - Renaming servers (and updating all the clients) every time a new app is deployed gets pretty painful pretty quickly. What happens when you deploy a 10th app to a particular server? What happens when you have hundreds of client machines that have references to a particular server name? db3.todoapp is more informative if the server only handles todoapp. If marketing decides to call the app "Organizer Pro" and you have 8 other apps on the server, managing the names gets to be pretty complicated. – Justin Cave Nov 6 '14 at 12:38
  • 3
    Also, what happens when machines have more than one function? Names either get unmanageably large or fail to accurately describe. – tom Nov 6 '14 at 12:39
  • 2
    It's difficult not to agree with back2dos. "non-descriptive hieroglyphs" is exactly what I was thinking about when reading your examples. The distinction between role and identity back2dos makes is also particularly relevant. At my company, servers are named according to their roles, and a name such as "http-blog-db-failover" appears to be much more explicit than "Hermione", and the name won't change when I switch from MongoDB to CouchDB or when marketing decides to change the commercial name of the website which hosts blogs. – Arseni Mourzenko Nov 6 '14 at 16:05

Naming things by their properties is a fundamentally bad idea. The reason is that properties are, by definition, changeable phenomena, while the identity of a thing stays the same even if properties are changed.

Someone decides that the file server should be migrated to Linux? If its name is "Apollo", that's not a problem. If the name referenced "windows", then it would either become misleading, or have to be changed everywhere at great expense or risk. You're introducing a new output format? For the love of God, don't call it 'newFormat'! It will eventually be replaced yet again, and the even newer format will need an even more descriptive name to distinguish it. Either call it '3', so you can later boost it to '4', or 'gold' so you can upgrade to 'platinum'.

(An additional reason is that names composed of nuggets of information are butt-ugly. No one wants to work on a computer named "PC-Marketing-Windows7-143" - they'll take "Apollo" or even "Bacchus" over that any day. But the main point is the identity/property divide.)

  • 4
    Descriptive names don't describe properties but purposes. If you call a function that displays output Hermes then yes, it's more recognizable than functionWithTenLinesOfCode. Personally, I would call it print though. – back2dos Nov 6 '14 at 12:13
  • @back2dos The examples the OP gives seem to be describing the equivalent of print_left_aligned_to_CRT_monitor() – Izkata Nov 6 '14 at 15:17
  • @Izkata: You have to admit, that's way better than Cathy(). note: I've personally seen production code with function and variable names quoting Guns & Roses lyrics and am guilty of writing production code with variable and function names referencing Buffy. – slebetman Nov 6 '14 at 16:45

There are 3 reasons, in my experience:

  1. When you have to name lots of similar things it can be hard to find unique descriptive names for all of them. People need a short unique way of referring to it, and we're better at using names than we are at using numbers (unless the number is very short). When you give it a name, it tends to take on a personality in your mind, so you'll remember that server Gandalf is the one with the flaky power connector better than SERWIN15AB23. It's also less likely that you'll confuse two of them with a typo.

  2. The naming process can be fun. Some companies do it with a vote. Other people enjoy coming up with unique names. Just ask any parent.

  3. For external projects, it's usually marketing that decides what the name is, and normally they do that right before it ships. When did Microsoft decide to call the latest OS "Windows 10"? I doubt it was always called that. The project might be in development for a long time before that, and in some cases you want to obfuscate it so people outside the company don't know what you're talking about.

  • 5
    It's also worth adding that names can be tailored towards the task in question. Gandalf might be the build server "where the magic happens", Cerberus may be the firewall, Hephaestus the dev server etc... it's very hard to associate numbers with functions – Liath Nov 6 '14 at 12:41
  • 1
    By the way: The internal name for "Windows 10" is actually "Windows NT 6.4". But the marketing would never admit that 6.0 aka "Vista" was the last version where the operating system kernel got a major redesign. – Philipp Nov 6 '14 at 13:22
  • @Philipp just type "ver" into the command line of a Windows 7 machine - 6.1 (vista SP1 which was always the joke), not sure what Windows 8 is off the top of my head. – Liath Nov 6 '14 at 13:43
  • Windows 8.1 Pro (I'm certain this PC doesn't have Update 1): 6.3.9600 msdn.microsoft.com/en-us/library/windows/desktop/… – WernerCD Nov 6 '14 at 14:03
  • @Philipp AFAIK, that's done for backwards compatiblity reasons, it doesn't reflect how much did the kernel change. – svick Nov 6 '14 at 15:16

Descriptive naming is hard™, it's much easier if you already have a theme which automatically comes with a list of words you can use.

When you have multiple of the same object naming them foo1.6, foo1.2, etc. quickly gets confusing/prone to mistakes. For example when you need to run your test on Virgo then you will quickly notice the mistake if you are happen to be on Cancer.

It also makes for an entertaining meeting when the naming conventions is rolled out and the decision is made to base the conference room names after music genres and you name the cafeteria Salsa.

  • Descriptive naming is hard™, it's much easier if you already have a theme which automatically comes with a list of words you can use. Very true. But just because it is easier, doesn't mean it is good in the long run. What you're saying not unlike not doing proper API design, because it's much easier to just churn out functionality. – back2dos Nov 6 '14 at 12:23

This may be related to high context or low context culture. Every company, organization, or team has its own culture. High or low context culture means how much information a culture likes to relate explicitly, and how much people are expected to take from context.

Naming all the services with names from cultural references does provide some flexibility, but also lacks explicitness. There has to be word of mouth or "tribal knowledge" that supplements the names -- i.e. the context of the service. I have seen situations where for example there's the "fizzbuzz" server, or the "marcopolo" service that no one knows what they do, but they get traffic, so they must do something.

I'm a low context person, so I tend to choose simple, explicit names that provide context about the purpose a server or service. I also write "self-documenting code" where I'm careful about naming in my code to make it more readable.

But I'm currently working in a high-context shop where all the services are named after Transfomers. Sigh. At least they use the names consistently.

So it seems more like a cultural value, but technical practices will adapt to the cultural preferences.

High-context can also be funnier, and there is some value in that.


The important question is: what is descriptive? The other answers have done a great job illustrating what is not descriptive.

Let's establish that descriptiveness comes from calling things by their role, their purpose. By what they do. For example, it's pretty clear, what a "cutter" does. Now it could be an ax, a laser or a knife. It doesn't matter so much. And a laser could also be a "pointer" an ax can also be a "decorator" and a knife can also be a "puncturer".

So, as others have pointed out, the relationship between the properties of something and the task it fulfills is relatively loose. Therefore OS being part of the server name is not descriptive, it is distracting from the true purpose.

Unless it is your job to work on how component DoesX accomplishes X, it is none of your business. If it is your job, then you are immediately confronted with it anyway.

As rachet freak pointed out, it is sometimes hard to find descriptive names. But more often than not, that is a sign of not having understood what the things do, that you must name. Before having that understanding, you probably shouldn't concern yourself with how it does that which you don't know ;)

  • +1, but what about adding an example? You may use the example I've used when commenting the question (http-blog-db-failover for a machine which hosts a failover database of a website hosting blogs; moving from Linux to Windows or from MongoDB to CouchDB won't affect the name, neither do marketing decisions.) – Arseni Mourzenko Nov 6 '14 at 16:13

One reason for codenames is obfuscation. If you make the name of a project meaningless, then you can talk about it in public without anyone else understanding what you are discussing.

Similarly, if you give your servers meaningless names, then nobody except the authorised users will have any idea what's on them.


The first reason is that it can be short and memorable. If you think about how many times you are going to say or write the name of the project, you save a substantial amount of time if there is a brief name that everyone knows and understands.

The second reason is that it builds camaraderie. If the team gets to pick the name, that can pick one that they all like. It is subtle, but it boosts team morale when you are working on a project named Viper or Gimley or Boba or Bugatti instead of a project named 'Q3 Accounting Updates'. I had a friend who worked on a team with a bunch of car enthusiasts. Their favorite project kickoff ritual was picking which car they would use as the project code name.


I've always thought this is something that's done mostly because it amuses people. People are conditioned by the media to attach value to skulking around in the dark vs. operating in the light of day. At age 5 we have "Special Agent Oso"; at age 15 it's James Bond. Secrecy lends an air of importance to people's otherwise mundane activities (e.g. programming a computer).

Relatedly, someone made a logo for "Longhorn" back when that was a Microsoft codename (http://en.wikipedia.org/wiki/File:Windows_Longhorn_logo.svg). Why would someone make a logo for a codename that's not intended to ever really be a part of any marketing effort? Again, people do this sort of thing because it amuses them. Playing around in Photoshop is easier / more fun than actually doing real work.


there may well be a system you just don't know.
One company I worked for used names of Nobel prize winners for all their servers. Different Nobel prizes indicated different categories of servers.
Test servers might be named after mathematics winners, database servers after literature winners, mail servers after medicine winners, etc. etc.
To someone not familiar with the naming convention, the names seemed completely random (especially as most people don't know all those hundreds of Nobel prize winners over the decades).

I've used a similar system at home, naming computers after jet fighters, servers after bombers, and disk volumes after volcanoes.

Same could be done with pieces of software, name production versions after trees, beta versions after flowers, etc. etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.