Naming things is hard

At the start of last year, the entire FoundryOS team squeezed ourselves into a meeting room to plan out the roadmap for the next quarter and beyond. We weren't starting from a blank sheet, but there were plenty of thoughts and ideas that were loosely defined and somewhat nebulous. We had lots of high-level concepts but had only just started to make them a reality.

One thing we knew we needed was a way to run processes; a series of steps that can take action on behalf of the system, to create and update data, to allow user interaction with that data, and lots of other activities. Someone got up and drew a big square box on the whiteboard and wrote 'Processes' above it.

"What are we going to call this?" asked Dave, our CEO and at the time, the person who best understood how FoundryOS was going to work. He knew that we needed a way of running processes, he knew the sorts of tasks that would need to be supported, but what he didn't know was what it should be called.

The team sat in silence as we all pondered the hardest task in product development: naming things.

Names are tricky things, especially in a technical or product context. You want something descriptive but preferably not too long. Something unique but not too abstract. It should resonate with the team, and immediately feel like the product or feature in question has always been named that way.

The problem is, all the good names are already taken. Just ask any new band that's starting out - trying to find a name that hasn't already been used by some 70s disco outfit or 90s shoegaze collective is a near-impossible task. The same is true for startups and products, which is one of the reasons why in the early days of Web 2.0 we got an endless series of products and services that took a noun or a verb and then removed one or more vowels from the word in order to stand out (and get the .com domain): Flickr, Tumblr, Writr. Even Twitter was originally named Twtrr.

The silence in the small, hot meeting room dragged on for a solid minute. I couldn't stand it any longer and simply said the first thing that came into my head:

"We should call it Steve."

Much laughter. We wrote 'Steve' in the box on the whiteboard and moved on with the rest of the session. Towards the end of the day, we were discussing processes again and it was suggested that maybe Steve wasn't such a good name and perhaps "Process Orchestration Engine" would be better?

"It's a bit duller," I said, "but it describes what it does." And so Steve was renamed to Process Orchestration Engine, or POE for short. Naming things is hard, but sometimes the sheer act of giving up and plucking the first name out of your head gives direction to a better, more fitting name.

The struggle to name things accurately came up again recently in an Engineering meeting, where we'd gathered to thrash out a couple of problems and resolve some long-standing niggles. One of these niggles was how some of our property naming conventions were confusing; patterns like '<thing>Name' and '<thing>Code' were being used in a number of places where neither was strictly accurate.

"OK, so what do we use instead of 'code'?"

Another long silence. "What about 'id'?" came the suggestion.

"No, that's already used elsewhere, and anyway, this isn't strictly an ID, it's more of a...well, a code."

"We can't use 'code', because it gets confusing when the property value isn't actually a code, it's a full kebab-case string."

"Arrgh, naming things is HARD!"

The meeting descended into an awkward silence. I considered suggesting 'Steve' again. Finally, someone broke the deadlock: "What about 'reference'? It's better than 'name' or 'code', since the value is actually more of a reference to a thing anyway."

We all agreed that 'reference' was a much better convention to follow. Jira tickets were written, documentation was updated and I breathed a huge sigh of relief as another naming catastrophe was averted.

Now, 'catastrophe' might seem a strong word to describe a simple naming issue and I am being a little facetious, but there is a serious point to this. At FoundryOS, we're building products and services that we hope will be simple to use and understand by our clients. Naming queries and properties so that they can be easily understood and used by developers is a vital part of designing APIs, just as much as naming the product or service itself.

That said, I'm still sad that our Process Orchestration Engine isn't called Steve.