Why is naming so difficult? We write functions and arguments, or classes and methods, all day long. Every one of them has a name. With all that practice, you would expect us to be good at it.

One reason is that names are always metaphors. When we say "open a socket", no actual opening happens. Our servers don't grow new orifices like a Transformer. All it means is that we arrange some memory like this and make that entry in a table (a metaphor of its own!) in the kernel (metaphor) of the operating system (metaphor).

In Metaphors We Live By, George Lakoff shows how entirely embedded we are in metaphors. They go much deeper than our primary school teachers have told us. Deep metaphors are ideas such as "Love is War," or "Happy is Up." Sometimes we form compound metaphors, which gain richness through their interaction.

My examples so far are pretty obviously metaphors. Now consider this relationship between three objects arranged linearly: you, another person, and a mountain. The distance from you to the other person is less than the distance from you to the mountain. You would probably say the person is "in front of" the mountain. That's a metaphor. The mountain does not have a front. The idea that the side nearest you is the "front" of the mountain is actually a cultural construct. Lakoff points out that in Hausa that orientation would be reversed. You would say the person was behind the mountain if it were between you and the big rock.

So we see that names can be problematic if the speaker and listener activate different metaphors when they use the same name.

Naming can also be an act of creation. By attaching a name to a phenomenon, we suddenly see that phenomenon as a "thing". Anyone who lived through the U.S. Presidential election in 2000 learned all about "pregnant chads", "hanging chads", and other mangled chads. (I wonder what happened to the frequency of baby boys being named Chad. Did it go up or down after that?) Prior to those tortured neologisms, nobody gave any thought to what you called that little rectangle of paper that got popped out of a hole in a punchcard. Unless, of course, you were in the punch card business. Or punch card machine maintenance, I suppose.

Pretty much every name we use in programming was created by someone, some time. Many are humdrum words to which we have attached our own meanings: window, list, queue, or string. Others are puns or derivatives: trie (from tree), zipper, virus, array.

Object-oriented programming demands tremendous naming ability. Some programmers don't do it very well, and you get classes like "AbstractHandlerManagerFactory" and "HandlerManagerFactorySingletonImpl." Yawn.

Because naming gives us a handle to discuss things, it can be useful to name "non-things" in order to "thingify" them. Even if it's a bit nebulous, you should always name your preferred architectural style, coding conventions, or pattern of interaction. Only in that way can you distinguish it from the older structure. Be careful though, because someone else may come along with an even more nebulous, foggy, but desirable sounding term and outmaneuver you. I contend that "private cloud" would have no traction but for the comforting sound of it.

(The term "in the cloud" seems to have originated with the telecom carriers. Specifically, in their sales groups. Sales reps were often unclear where or how the service was actually being delivered, so they would draw the customer's locations on a diagram, connect them to a fluffy cloud, and show call-center people "in the cloud" handling the customer's calls. That became shorthand for "you shouldn't care where the service is" even though it originally meant "I don't know where it is.")

Once a name is created, it is impossible to destroy. Even when the concept is long past its natural life, it can be difficult to get rid of it. For example, imagine saying "we no longer need a User Acceptance Testing environment because we aren't going to do User Acceptance Testing any more." It sounds like the height of irresponsibility. Removing a flavor of testing is enormously difficult, even if you can prove that it caught zero defects over the last five years.

Fans of Jacques Lacan would describe this as the difference between a thing's death in reality (the death of the thing) and its death in the symbolic order (the death of its name). The "symbolic order" can be language, or ideology, or any other shared symbolic or metaphoric framework for trying to make sense of the universe. ("Agile development" is an example of a symbolic order.) A thing can become useless in reality, but remain quite useful in the symbolic order. For example, let's say your UAT testing never actually uncovers any bugs. (And let's also assume that your software is not perfect, and there are indeed bugs to be found.) Your UAT testing serves no purpose in reality. It's dead. But saying "we're not going to do UAT anymore" sounds irresponsible precisely because "UAT" is a familiar component in the symbolic order of your development process. If you remove "UAT" from that system, then suddenly the validity of the entire symbolic order becomes questionable. That's terrifying. (Or liberating.) Therefore, in order to prevent existential despair or psychosis or revolution, you might cling to this superfluous concept of UAT. This happens anytime you're going through the motions of some empty ritual. You do that because you haven't figured out how to reconfigure the symbolic order to account for reality. You haven't figured out how to rename things.

-Maggie Litton, Relevance coach and literary theory buff

Another tough thing about names is that they are almost always compounds—that is, they bind multiple concepts together. A single noun can give the illusion of conceptual unity. Most of the time, that name can be decomposed into constituent concepts. This is especially true in the world of domain modeling. For example, last week I was in a lengthy discussion at a retail company about the proper owner of "Cart" functionality. Everyone thought they knew what Cart meant, but when we enumerated the different aspects of Cart we found 8 - 12 distinct uses and behaviors. Cart is, of course, a metaphor. There's no secret underground facility where wire-mesh wheeled vehicles wander around letting goods drop into them. Once we started splitting those distinct behaviors apart, we found that Cart actually wasn't a thing at all. Rather, it was a label for a compound of several different things interacting together.

Sometimes we name things to separate them from other things. Retronyms fall into this category: "feature phone" versus "smart phone", "dequeue" versus "queue", "trie" versus "tree." This can be an effective maneuver in a political environment: when you need to steal the wind from another group's sails, name your project such that the semiotics imply superiority. Good words to use here are "open" and "version 2.0." If the enemy project uses names from classical literature, find out who slew their project's eponymous hero. Or, if you want to get in front of Sun, name your project "Eclipse."

Naming is difficult. But it is also a primal, shamanistic power. When you name, you are literally exerting mind control. Use it wisely.