Maciej Galeja

,

About names in software

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

Phil Karlton

We embraced agility. Software is made in agile way, and we welcome change. Ok, that may be too far-fetched, but there is something about it.

Software systems change. This is the way it is supposed to be. We add new functions, deprecate old ones, and we need to make sure that the name still represents the main purpose. Or do we?

Some things cannot be changed so easily

It’s easier to change the code than the project name. Changing names often causes unnecessary interruptions and the need for adjustments. Just imagine what would happen if URL of a dependency changed. It is a lot of maintenance effort that could be spent developing application.

We need to name software components. Naming them after their purpose or use case may not be optimal. What if the functions change? The library does something else, but we can’t change its name, because too many other components depend on it.

What to do?

Since names are so important, and we can’t really change them, maybe we can just make them less important.

Server naming has a tradition of using codenames, which are easy to remember. It can be anything, from cool sounding, catchy names, to characters from movies or books.

This is a way to fill the “name” field with something that has a chance to make sense for a long time. And if it is a catchy name, people will remember it well and will not confuse it. Of course, for someone from the outside it may be tricky in the beginning, but with time they will get used to it.

Examples

Whether to pick a descriptive name, or a playful one is not an obvious choice. And the landscape has some of each approach.

Creative naming

Name of the main project in the ecosystem may be a starting point for other projects, for example: Python and Anaconda, Cobra and Viper in Go, or Docker and Moby.

I think there is nothing wrong with creative names like Bouncy Castle, Gin or Django. You don’t know what they do at first, but then you just remember it.

Names corresponding with the function

On the other hand, we have projects and libraries that (more or less) precisely describe the function, like SSH, log4j, rsync, robocopy.

With the examples above, it feels like their function is clear, and unlikely to change in the future. Because of that, it was a safe bet to name them like this.

Inspirations

If you want to play with naming, and run out of ideas, here are some real-world examples:

There are many more. They are usually used for release names, but the same rule can be used for naming repositories, servers, databases, and basically, anything that needs to have a name.