Comments on: Killing Code Names http://www.symphonious.net/2006/08/16/killing-code-names/ Living in a state of accord. Tue, 07 Feb 2012 01:07:58 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Brad Appletonhttp://www.symphonious.net/2006/08/16/killing-code-names/comment-page-1/#comment-30140 Brad Appleton Sun, 27 Aug 2006 13:08:26 +0000 http://www.symphonious.net/2006/08/16/killing-code-names/#comment-30140 Code-names existed for a reason ... to quell a tension between development and marketing! Development (and CM) folks had this crazy idea that version names/numbers should correspond to some logical scheme whereby each set of numbers & letters separated by a '.' or '-' or '_' actually has some logical meaning. Such crackpot ideas gave rise to release naming and numbering conventions. Marketing didnt like this! The release name (like the release itself) is a marketing opportunity and the release numbering has a psychological impact on users and customers that cause them to make certain assumptions (ofr better or worse). So marketing wanted to set the officially advertised release name/number based on how they felt they could manipulate perception rather than based upon some logical convention brainstormed by analytical geeks. Marketing won that battle - a lot! So to combat the effect of having a rlease start out with one release-number only to change into another after marketing got their hands on it, the "internal name" or "code name" was born. "It doesn't matter what marketing calls it now - we'll still just always use the code-name internally. Then when they turn our "0.2" into "1.0" for marketing purposes ... we can still all use the same name we were using before. We just 'add another level of indirection' to our naming convention to 'encapsulate' identifier-name changes made by marketing." The problem was, the code-names started getting communicated and werent completely 'internal only'. And once the code-names "slipped out" into public consumption, lo and behold another marketing opportunity was born. Combined with the release name - this was now two for the price of one. And so it went ... Seriously tho - there really are genuine times when we have a project in its earlier stages and while the major features may be nailed down, the rest of the content isnt, and neither is the exact date (or even month/quarter of its release). If a logical numbering convention is used, you may not yet have enough knowledge about what the final release-name will be. Some naming conventions take this into consideration, using the first two segments of the name for the hi-level planning and letting the rest be fleshed out later. It can still be sensible and beneficial to use internal code-names at this point. But the code-names werent originally intended to be used in comminications with the customer/end-user. All that has changed now Code-names existed for a reason … to quell a tension between development and marketing! Development (and CM) folks had this crazy idea that version names/numbers should correspond to some logical scheme whereby each set of numbers & letters separated by a ‘.’ or ‘-’ or ‘_’ actually has some logical meaning. Such crackpot ideas gave rise to release naming and numbering conventions.

Marketing didnt like this! The release name (like the release itself) is a marketing opportunity and the release numbering has a psychological impact on users and customers that cause them to make certain assumptions (ofr better or worse). So marketing wanted to set the officially advertised release name/number based on how they felt they could manipulate perception rather than based upon some logical convention brainstormed by analytical geeks.

Marketing won that battle – a lot! So to combat the effect of having a rlease start out with one release-number only to change into another after marketing got their hands on it, the “internal name” or “code name” was born.

“It doesn’t matter what marketing calls it now – we’ll still just always use the code-name internally. Then when they turn our “0.2″ into “1.0″ for marketing purposes … we can still all use the same name we were using before. We just ‘add another level of indirection’ to our naming convention to ‘encapsulate’ identifier-name changes made by marketing.”

The problem was, the code-names started getting communicated and werent completely ‘internal only’. And once the code-names “slipped out” into public consumption, lo and behold another marketing opportunity was born. Combined with the release name – this was now two for the price of one.

And so it went …

Seriously tho – there really are genuine times when we have a project in its earlier stages and while the major features may be nailed down, the rest of the content isnt, and neither is the exact date (or even month/quarter of its release). If a logical numbering convention is used, you may not yet have enough knowledge about what the final release-name will be.

Some naming conventions take this into consideration, using the first two segments of the name for the hi-level planning and letting the rest be fleshed out later. It can still be sensible and beneficial to use internal code-names at this point. But the code-names werent originally intended to be used in comminications with the customer/end-user.

All that has changed now

]]>