It seems to be a recurring discussion in the companies I have worked for: should we use a codename for this project or not? These are software projects. The codenames are used on things as basic as the repository name or slack channel. Later, they might be used in many other project-related things like the build server configuration. The alternative for a codename is calling the thing exactly what it is. Where’s the fun in that?
The Argument Against Codenames
The argument is that if you call the project what it is, people will know what you’re referring to when you talk about it or when you see it in your version control or on the build server or hear about it at lunch.
I think codenames are fun. They add identity and character to your project. They contribute to team spirit. You have marketing options in a codename via logos, mascots, and themes. Most things you can do to increase the cohesiveness of a team around a shared identity, sense of belonging, and to increase their enthusiasm will be worth it. Why not let codenames help you with this?
An environment where codenames are enjoyed is one that is not sterile and colorless. There are people and product markets that specifically enjoy things and places that are not organized in clean, labelled boxes. Bring some color to your environment, learn to stop worrying, and love having fun together.
They Encourage Learning
When you hear a codename for the first time, you might not know what it means. Is that an unusual or bad thing? Not knowing what it means should encourage you to ask what it means or look it up.
After you do, you’ll then have learned it. You’ll have connected with people that know about it. You’ll have found the documentation detailing what it really is, not just what you can fit into a name. I like the idea of each project having a root readme file that describes the core ‘What’ and ‘Why’ of the project.
Codenames are usually shorter than any presumably more descriptive name. This is great because we usually are talking about our projects or teams all the time. Thus something long and descriptive, like a bloated government agency name, is likely to be shortened into an acronym instead (which is just a codename constrained by odd letter combinations). Worse still, as people tire of saying the longer name, they start making up their own easier-to-get-out versions which will not be consistent.
We Speak a Specialized Language With Each Other
Codenames are great for the usually-specialized teams that end up working together. These teams speak a common language that they learn because of the domain they all work in together. It’s a specialized language. This is common for other technical and specialized groups: For example, air traffic controllers speaking to pilots on the radio will use terse, specific terms that others outside the domain don’t necessarily recognize but which the two parties have learned to use together. If your teams are cross-functional, you should learn the lingo common to your domain.
They Need Discoverability Help
Codenames do not help with discoverability. In the age of search, however, this point is lessened. We often put important domain-related keywords next to content. I’m all for including bylines next to codenames as a one-line explanation of what it is. Using a combo like this when it makes sense will give you the best of both words: exact consistency via the codename and some discoverable verbiage via an accompanying byline.
They’re New Words
A codename a variable name. It’s an abstraction. It represents a project, team, codebase, or something else. It hides the internals. It will outlive your company’s pivot from the original project scope and meaning so you can keep your codename even as your mission changes. It usually doesn’t leak the internal implementation details.
Codenames are singletons within the universe of your company. No one else will have the same team name, repo name, or slack channel. Codenames are the keys in the dictionary of values.
After you learn a codename once, when it’s mentioned, you’ll know what it is. Nbd.
They’re All Around Us
Codenames are all around us, thankfully. Who really wants to call Kleenex, “facial tissue”, anyway?
You’ve heard of Python, React, maybe even Chaos Monkey (and check it out, they even have a ‘What’ and ‘Why’ in their readme!). You’ve probably also heard of Microsoft SQL Server. Blegh. Doesn’t that fill your soul with the emptiness of corporate sterility. Though, there are codenames in their too, right? “Microsoft”. “SQL” (one of those weird descriptive-things-turned-acronym).
So, embrace codenames. You use them anyway. It’ll be more fun for most. It’ll bring color to your world. It’ll bring life and character to your team identity and the discussions you have about what you do.
What are some of your favorite codenames, and what are some of your favorite reasons for using them?