An important consideration for the cognitive tie between stakeholders and a project is its name. In the software industry, project code names are often chosen for their whimsy and are often part of a series for which the stakeholders have a special affinity. A similar phenomenon occurs in the naming of IT system resources.

• Naming is an intrinsically difficult task for people to perform.
• The named entity gets elevated to pet status, making it difficult to part with.
• Organizational changes and new employees may introduce new series, yielding a partial consistency which is ultimately confusing.
• Resource-consuming debate over naming arises in democratic or consensus environments.
• Nomenclature may collide across business units; i.e. the same name may refer to different things in different parts of the company.
• The semantics of the entity's name may restrict, hedge or otherwise affect thinking around how it can be used.
• Retroactive renaming is more confusing than just leaving the mess alone.
• Better off creating a controlled mess at the outset than having an uncontrolled mess later on.

The solution I propose is to extend the technique of code-naming through the use of randomly-generated cryptonyms. These cryptonyms would essentially be nonsense words invented for the exclusive purpose of uniquely identifying an entity. Essentially, I'm suggesting to start code-naming projects stuff like this:

It may look silly, but I suspect Big Pharma and Web 2.0 companies have been doing this for years, for ultimately the same effect: have an unmistakable word that uniquely identifies your property and doesn't mean anything else. Here is a sketch of what I imagine to be the requirements of the properties of these cryptonyms:

Unambiguously pronounceable and writeable in most languages

The phonological and lexical structure of the cryptonyms would be constrained to a reasonable subset, allowing for signal restoration if the word was mispronounced or incorrectly transcribed.

No accidental interpretation

Upon generation, each word would be checked against several dictionaries to ensure that it was gibberish. An issue here occurs with isolating languages, such as the Chinese langauges, where each syllable is its own word. It is also worth considering the documented psychological relationship between sound and form.

No sense of scope or sequence

It is important to not be able to infer that a particular project the fourth attempt at a certain result, or that an object is business-critical or not. As such, cryptonyms should not contain any pattern or component that classifies them. Contrast the CIA, which used a two-character namespace prefix on its operation code names to indicate to some extent what they were about.

Enough entropy to satisfy decades of operation

16 bits of entropy (65536 combinations) would be well enough for most organizations. 32 bits (4294967296 combinations) would satisfy Microsoft for four centuries if every one of its employees were to start a new project every week. The length of the symbol could also contribute toward its entropy.

In practice, I have begun using a random pronounceable password generator and cherrypicking the results. I wrote a trivial program that uses Chia-Liang Kao's Perl module Text::Password::Pronounceable, which seems to be sufficient for now. I have also begun using UUIDs as temporary identifiers, especially for URIs, for which I have yet to decide on a permanent value.