On Project Code Names
By Adrian Sutton
Maybe I’m just a spoil sport but I think project code names are the most ridiculous concept. I’ve never seen a code name help clarify things – they only ever cause confusion. Compare:
Hey Joe, how’s the schedule looking for futzbist?
with:
Hey Joe, how’s the schedule looking for the next EditLive! release?
The argument is of course that everyone gets to know the project code name so it’s a nice shorthand for the project – but for how long do they remember them? How far back can you name Java, Ubuntu, Debian or even OS X releases? Did Puma come before or after Cheetah? What was the Tiger release? And what’s in the stray alley cat release?
It mightn’t seem important to remember historical project code names, but if you happen to be reading documentation that was written in that era it is. Bug reports don’t tend to just disappear after the project you know… The Java bug parade used to be (and sometimes still is) painful to try and extract information from because it refers to Java versions with code names.
Even in the team, it takes time to get a code name off the ground and actually usable – while that’s happening you constantly have to add some other moniker to the release to clarify what you mean. Why go through all that pain, why not just decide on it’s final, public name up front and stick with it?
Marketing often argues for code names on the basis that then they can tweak the version number right at the end of the release. Why is this so hard to decide ahead of time anyway? You should have a pretty good idea of what features are going in and how important they are before the project gets to the point where it needs a name.
The bottom line is, if you can’t think of a single thing that you can anchor down about your release and use as a way of referring to it you’ve got a serious planning problem. Maybe it’s the April release, maybe it’s the next release, maybe you know it’s time for a major release so it’s 7.0 or maybe you know the key functionality you want to add. Refer to your project using meaningful about the project and as quickly as possible get it a final name. For example, right now the engineers are working on the 6.4 release which prior to actually being scheduled was the divs release. I think there’s been about 3 attempts to give it a code name and all of them have caused confusion, but the divs release was just so natural and obvious that it worked for everyone immediately.
That said, the other project on the go is known as E2 which is a classic code name – true to form, we spent a year or more trying to work out what it was. The name stuck before we actually worked out what the project was. I’m a little concerned about how long we’re going to spend replacing E2 with whatever name we wind up coming up with for it. I don’t think it appears anywhere in the code or the product at the moment but there’s a massive amount of documentation and discussion that will cement the term E2 in Ephox’s corporate lingo for a long time to come.
This rant was triggered by Jeff Atwood.