The day I loose my linguistic nimbility will be the day I leave the software industry. You might ask what is linguistic nimbility? or LN for short. Well, linguistic nimbility consists off two skills. First, is the ability to determining the meaning of something given a short series of capital letters. Second, is the ability to understand what someone is referring two when the name for the thing has changed 3 or 4 times over the last 6 months.
After working in any industry for quite a while you start to notice certain peculiarities. A peculiarity in the software industry is the extensive use of acronyms and code names resulting in the need for LN.
First let’s look at the acronym talent. We in the software industry use acronyms because we are too lazy to type the same descriptive words over and over. Since much of our communication is through the written word, one can see the argument for the use of code letters to assist us. For example, the project I am working on right now is Visual Studio Team System (quite a mouthful). This shows up time and again in specs and e-mail as VSTS. There is also Visual Studio Team Foundation (VSTF) and Team Foundation Core Services (TFCS). Suppose I said “TFCS is part of the VSTF which is made up of the TFC and TFS. TFC is the client side of TFS and is included in all VSTS clients”. Now, if you have LN then you will be able to tell me what TFC and TFS stand for. Can you?
Another thing worth noting about acronyms is there are two types. Those you can pronounce and those you can’t. Thankfully (for me) VSTF is not one of the prononceable kinds. The curse of software acronyms are those that can be pronounced. These drift across from lazy writing and into the vernacular and the original meaning is soon lost. One of my favorites is ‘misskee’. Misskee is used often in the Windows SCM (software configuration management) arena when discussing Microsoft’s source code control interface. Ok, if you’re linguistically nimble you have now astutely determined that misskee is MSCCI.
The second peculiarity that leads to a need for LN is the code name problem. Everything in software has to have a code name. Why is that, you might ask? The reason is that no-one is allowed to name a software product or component except for marketing. And marketing is not willing (and rightfully so) to name a software product until the very last minute before it comes out. So, software teams come up with code names to refer to the product or feature they are working on.
This leads me to the real problem with code names. Software teams want cool code names. I mean hip and groovy ones that they can show off on T-shirts. They also like to pick names of things that there are a lot of and that everyone knows about so they can start a trend and not run out. For example, mountains, rivers, streets, parks, and yes even beers. I’m still waiting to work on the project that uses Tequila code names. I really want to say “I’m working on the Cuervo project”. Code names are never picked that could be misconstrued, whose reputation could be soured during the life of the project, or would make the team look silly. For example, you don’t find software code names like Mickey, Donald, Goofy, Clinton, JLo, BackStreetBoys, Dumass, Barney, or The Wiggles.
Visual Studio Team System used to have the code name Burton (before marketing picked VSTS). This may seem pretty dull unless you are in the ‘NO’. Burton is a major line of snowboarding gear and that means hip, groovy, cool, and r-a-d rad. The project I’m working directly on is called Currituck. This kind of code name should really be banned all together. I’d tell you what it was named after, but then you could guess all our other code names and I’d have to kill you.
This leads me to the other problem with code names that requires the up-most of linguistic nimbility and that is code name churn. Code names change and sometimes frequently. This can happen due to re-orgs, new management, or just because an old code name has gone out of style. When this happens you find old presentations and specs using old code names or even mixed code names if someone updates only part of a spec. There are confusing transition periods where new code names are being picked up while old code names are being used. You also find that things like web site URLs and e-mail aliases take on a retro flair as they are often left untouched as code names change leading people to wonder why these alias/sites have such weird acronyms. My favorite right now is a sub-project of Burton which delivers a set of core services to the whole of VSTS. These were originally called FlexCore. Rumor has it that this is a certain technology that makes up the center of Burton snowboards (clever eh?). This changed to BIS at some point. Right, Burton Integration Services. Later this moved to TFCS or team foundation core services.