What's In A Name?

There are only two hard things in computer science: cache invalidation, and naming things.  —Phil Karlton

For functions and variables, the perfect name tells the reader exactly what they're looking at. But what is the perfect name for a service, library, or module?

I've had the pleasure of working with Llewellyn Thomas, who would argue that the same principle applies. You name your thing to help your fellow engineer who is spelunking through directories to make sense of the codebase. webhook-caller; legacy-crm-adapter; user-signup-handler. The more descriptively the things are named, the less cognitive load is involved in understanding the whole.

Another memorable character I worked with – let's call him Escalus^† – would point out that the scope of a thing tends to drift over its lifetime, and that the fidelity of a descriptive name has a half-life. Eventually, the name of a thing is so inaccurate that it actually obfuscates. As such, Escalus favours opaque names, forcing readers to peek inside where an up-to-date description is waiting for them. Changing a description is cheap.

Llew would counter that the tension between the name and the scope of a thing is a feature. webhook-caller prevents accidental scope drift – a sort of onomastic version of Conway's Law. Personally, I'm not so sure. While I can see how a descriptive name protects focus, I can just as well imagine it hindering a thing's ability to adapt to changing requirements. Predicting the ideal scope of a thing at its inception is difficult.

Both positions have merit. But there's an angle I think we're glossing over: naming is a great opportunity to let some of the personalities of the humans involved shine through, and to strengthen their sense of ownership. Instead of agonising over the most efficient name, consider letting some creativity in. Borrow some lingo from your hobby, reference your favourite film. Craft a name that fits your team. And perhaps user-signup-handler is exactly that.