There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

There seem to be two breeds of thought on naming in software: literal and captivating. I think that literal speaks for itself but the idea of a captivating name is that it invokes the imagination to associate something unique with an abstract idea.

An illustrated example is a discussion between several of my coworkers, debating what to name a reporting service. For context my company has a long history of naming large projects after Norse gods.

"What about Hel?", proposed John. "Hel? What does that mean? We should call it Metric Reporting Service.", Steve suggests as a counter example. Steve had a long history of proposing literal names and absolutely abhorring the Norse god naming scheme. "You know,.. I bet Steve named his dog 'Outside Poop Machine'.", retorts John.

It was at this time that we all burst into laughter.

I've found that I enjoy a more captivating and abstract name for larger projects. In the same way that people name conference rooms, a unique name helps solidify and captivate the imagination around an otherwise mundane or ordinary thing. There are limitations though and over time I've found that as the number of captivating names increases the value is lost. Perhaps this was Steve's point all along. As the newest memeber to the team he was introduced to a long list of abstract names.

• Thor
• Hel
• Loki
• Rattoskr
• Odin

... and so on. Being presented with so many abstract names they lose the sense of captivation. Whereas the rest of the team had to opportunity to slowly grow the list, picking some of the names themselves. After a while though, as a service is finished and runs in production much of the team, especially if they didn't name or work on the project directly will lose the captivating association as well. At this point, the literal name has the advantage.

The aspect of literal naming that fails for me personally is when something's description doesn't designate what makes it different.

An example:

    var logProperties = util.getProperties(data)

This is a contrived example but there are a range of words used in programming that I think have lost their meaning: log, data, build(er), config, properties, object, obj, and the list goes on. There is a point where literal descriptions fall back into the same pattern as that of the captivating scheme, meaning is lost.

I have no idea, naming is still hard. Perhaps like estimation, multiple vectors could be used to generate better names or using a thesaurus on really important items.

Alternatively there is a chance that there is no solution at all and naming will simply be hard to get right. Or its only when we get rid of names entirely (lambdas, declarative systems) that the problem can be solved through avoiding it all together.