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.

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.)

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.

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.

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.

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 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 😉

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.