I was recently discussing the nature of bizarre acronyms with Wallace in a local drinking establishment. Our meeting was as a pretence for me wanting some tips from him for an upcoming interview I had, and I was sharing the tale of a former manager who should never have been allowed to name things.
Years ago, before I was working in schools, I was a junior programmer on a section of a project dealing with aircraft fatigue. As such, all our code modules were prefixed with the letters ‘FAT’. There would then be a two-letter code describing the aircraft type (e.g. ‘HA’ for Harriers), then a ‘C’ to denote that it was a Code module. This was all fine until we came to the Common code module, which under the approved naming system, was assigned the name FAT_COC.
I wonder to this day whether this was the plan all along. A few months before I left, the same manager developed the Fatigue Template Integration Test System. The resulting acronym was also – incredibly – not vetoed by senior managers.
A common misconception about acronyms is what qualifies as one. In fact, they are only acronyms if they are pronounced as a word. If the letters are spelled out in speech, it is not an acronym. Hence, RAM is an acronym, but CPU is not; it is merely an abbreviation.
But, I digress. Wallace clearly decided he needed he needed to go one better, and last week emailed me with news of his latest discovery. He described the phenomenon that some users exhibit when they know there is a server problem, whereby “the user who has deleted shortcuts from the start menu, or jammed twiglets in the paper tray of their printer”, blames the completely unrelated server issue, just because they know it exists.
He named it “Bloody Unjustified Multiple Technical Issue Transferal Syndrome”. The acronym certainly expresses the ridiculous nature of the phenomenon. Anyone care to contribute their own creation in a similar vein?