Management Good luck with that

The Codename Rules

A long time ago, there was a big fight between Engineering and Marketing regarding the name of a new 1.0 product. I was not there, but the fight went something like this:

Engineering: “So what are we going to call the product?”

Marketing: “We’re not sure yet. The focus group data isn’t complete.”

Engineering: “A focus group is going to tell us what to call our product?”

Marketing: “No, we gave them a list of 20 different names and they’re going to determine which name strategically distinguishes the product from our competitors by conveying its unique positioning.”

Engineering: “Screw that.”

Knowing that they’d lose a marketing battle with Marketing, but wanting to have some minor say in the name of the product, the Engineers made up a name for themselves. It was their name for their product and you’ll never know many of these names because the engineers just invented codenames.

Codenames are Stories

Product codenames are the mysterious cousins of official product names. They are intended to be disposable and are often designed to obfuscate rather than illuminate. For me, a good codename needs to meet a set of requirements because they define an important and personal part of engineering culture.

These are my rules:

Codenames are chosen by the folks building the product. The people who are building the product are the only ones qualified to pick the right name of the product. If Marketing is picking a codename then you don’t work at a product company – you work at a marketing company. Good luck with that.

The best codenames are emergent and never picked by a committee. When the idea of a product has enough velocity to deserve a codename, start listening for it. It often just shows up. High quality codenames are emergent and there are likely going to be two or three wandering the hallways before one just sticks. Be open to organic codename rejection and never ever call a “let’s name the product meeting”. Just listen.

Codenames have multiple levels of meaning; they tell the story of the product. At my first startup, our platform was failing. We’d built it too fast in an attempt to beat competitors to market, and it was missing essential features. One of our senior engineers spun up a product to address the feature gap and after three weeks we called it “Snowball”.

When anyone learned the codename, they laughed. They laughed because they got it – they knew we had a snowball’s chance in hell of building this product in time. However, they also knew the other intended meaning of the name. They knew of all the engineers on the team, this engineer was the one most likely to produce a product we could build on. He was an architect and he built with expansion in mind. If he was successful, he’d give an initial product that would build on itself – you know – like when a snowball rolls down a hill.

There are bonus points if a codename is “nerd interesting”. A codename usually has nothing to do with marketing. It’s cultural documentation of a product. As such, codenames tend to emerge from the nerd domain of interest. This is less a rule and a more of a “nice to have”, but when a codename meets all the other criteria and remains steadfastly nerd interesting, I mentally clap. Especially since…

Codenames are one word. Exceptions are few and far between. The reason? Efficiency. A codename is chosen as a time saver. My first significant product, Paradox for Windows 1.0, had a great codename “Tsunami”. It met all the requirements: a single word, nerd interesting, and it simply told the tale of what we were attempting to do with the product – there’s something big coming, we’re building the first easy to use relational database to the then-emerging Windows platform. Good codename.

For our subsequent release, we had a codename contest (fail) because the different parts of the the project – the front-end Windows application and the back-end core technology team – each wanted to be represented (lame). We eventually dubbed this new version “Thelma and Louise” which was a fine movie, but a really shitty codename. Say “Thelma and Louise” ten times fast and remember that you picked this name as a convenience… not as a verbally stumbly hindrance.

Never let mechanics pick codenames. The more Vulcan-like on your engineering team are going to want to build structure into your codename process, and as a general rule I think it’s elegant when a codename allows for future codenames that show discernible progress. In a less inspired time, I picked “Redline” as a codename because I was currently fascinated with ice hockey. The subsequent releases had a different lead and he picked Orangeline as the next release name, then yellow, green, blue, indigo, and violet. That’s ROY G. BIV for you wavelength nerds in the audience. Brilliant.

For each engineer who is up to the task of inventing clever and elegant codenames, there are the mechanics who want to beat the living poetry out of them. Resist these engineers. They will have compelling arguments for why calling the release “Q1-A-4” is the right thing to do, but their arguments lack poetry and entirely miss the point.

The Point

Years ago we, the product team used to get boxes that contained the printed documentation and media that came with the first version of the products we built. The Internet has mostly replaced this channel, which means when we’re done with a product we, the dealers of bits, confusingly have nothing to show for it. T-shirts help, but a t-shirt is just a conveyance for an idea, for a name.

Codenames document your product culture and there is an economy to these names. Every single product in your company doesn’t need such a name. My rule of thumb is that a codename designates a product or project of significance. What is significant is entirely up to you, but I know that you will never make a project significant by giving it a codename. If your idea or product is shitty, a codename will never help.

Leave a Reply

Your email address will not be published. Required fields are marked *

9 Responses

  1. Greg Finnegan 3 years ago

    Great post. We had two rules – #1: the name had to be a short 1-2 syllable word; and #2 releases needed a theme (e.g. Futurists – Dyson, Bucky, Isaac for the Mac versions; and of course Bill for the unshipped Windows version…)

    As I’ve moved into internal projects I continue to apply #1, but I lean towards trying to find a codename that is so good, it just gets adopted as the product name.

  2. Years ago, Nissan (it may have been Datsun back then) was introducing a new sports car to the US market. The powers that be in Japan called it “The Fair Lady”. The head of Nissan USA knew that name was doomed to failure, but for cultural reasons could not disobey his boss.

    His only option was to roll out the car using the code name that it was called internally. It was the 240Z which not only became a great car, but started a line of numerically named sports cars.

  3. Ryan Fox 3 years ago

    I used to work at RIM, both as an intern and eventually full-time. When I first started, we had codenames like Electron, Positron, Gamma Ray, etc. Later on, after the iPhone came out, (probably not related) they decided to go with US National parks (Yawn. Also, a weird theme for a Canadian company!) When I left a year ago, every product was literally called R### (where ### is replaced by some seemingly random numbers).

  4. /on the tea/on the team/

    nice typo

  5. Miles Archer 3 years ago

    All good rules. Here’s my addition – Code names have to be pronounceable and easily spellable to non-native english speakers.

  6. For shorter release cycles, I am becoming a fan of alphabetically ordered, thematic codenames. You never have to remember whether Ninkasi came before or after Rogue as long as you can sing the ABCs. But for longer release cycles, I prefer a more organic approach.

    One other rule that you should have mentioned, no mention of codenames in the code itself. “Why are all of these classes prefix with TSU? And these other ones with T1?” Comments are OK, but variable names or class names are not.

  7. Cecil 3 years ago

    A long time ago, marketing at the company I was at didn’t “get” the product, and couldn’t figure out how it fit into the product mix. They won an internal war, and our project was shut down… but since we were the #2 revenue source at the company, they couldn’t afford to just stop selling it.

    As a compromise, management gave us 3 stability releases with no new features, only “reliability improvements,” over the next 18 months before the project would go into maintenance mode.

    So we came up with code names for them:




    About the time ICARUS was released, there was a revolution that ended up with a new marketing group with all-new ideas about what the company would do, and so we were brought back into the fold. Management still liked the idea of reducing support costs and increasing reliability, but we were allowed to introduce new features. We were also encouraged to have less-pessimistic code names and so we went with:




  8. Codenames are like pet names between lovers, and you generally don’t want to subject outsiders to your inner fantasy world. Bigwuvs and Snookums can have their fun in a private room, but when it comes time to ship the code out to an external team, say the systems guys, stop using code names and refer to the product and its next version number.

    This: “We need you to deploy Hitchhiker’s Guide 3.7 on Dec 5.”
    NOT: “We need you to deploy Slartibartfast on Dec 5.”

    The external team know what foo.oh means, but they can be forgiven for not being hip on or even remotely interested in your internal product code names, which can serve to introduce layers of confusion and annoyance.

    PS Nice fonts here, sir!

  9. unhinged 3 years ago

    “… beat the living poetry out of them.”