Acronym Amplification

A warm welcome to our newest regular contributor, Mike Pope. As a longtime technical writer and editor at Microsoft, Mike has developed some special know-how in that favorite techie shorthand, the acronym. Here Mike explains the ins and outs of acronyms and initialisms.

The most general editorial advice you'll find for acronyms (and initialisms) is "spell out on first mention." This is reasonable; here are a few examples:

• You need at least 30 gigabytes (GB) of free disk space.
• Caching keeps commonly used objects in random-access memory (RAM).
• Search Engine Optimization (SEO) refers to a collection of techniques to improve your site's ranking in search engines.

Obviously, the idea is that if readers are unfamiliar with the acronym, they'll be clued in for subsequent references to it. I posit, however, that in practice, following the "always spell out" guideline will not always delight the reader.

Suppose you're writing about the USA or about TV. Spell out? You might think that's going a bit far. If so, you're in good company — the supremely level-headed Carol Fisher Saller at the Chicago Manual of Style puts it this way: "When consistency gets silly, you can rebel."

There probably aren't that many acronyms that reasonable people could agree are universally understood. But all writing is aimed at a specific audience, and it's a very fair question to ask whether everyone in your audience understands a specific acronym.

A style guide will often help. Our guide at Microsoft (MSTP) lists common acronyms for our field, what they represent, and whether we need to spell them out. Here are just a few of the acronyms on the "yes, please spell out" list:

• DNS (Domain Name System)
• ISV (independent software vendor)
• OOP (object-oriented programming)
• RAID (redundant array of independent disks)
• RTF (Rich Text Format)
• SDK (software development kit)
• XSL (extensible style sheet language)

Whereas the don't-bother list includes these, among many others:

• AC (alternating current)
• API (application programming interface)
• CD (compact disc)
• GUI (graphical user interface)
• HTML (hypertext markup language)
• I/O (input/output)
• PC (personal computer)
• PDF (portable document format)
• USB (universal serial bus)
• WYSIWYG (what you see is what you get)
• XML (extensible markup language)

For terms in the second list, the guide does say "Spell out if not familiar to your audience." But in my group, we take exception to even some of the terms in the first list. For example, in our material for advanced programmers, if we spell out API and OOP and SDK, we're going to look like a calculus teacher who's explaining how to add fractions.

A second exception to the "always spell out" guideline, and perhaps one that's more controversial, pertains to acronyms where spelling them out simply isn't useful — as in, if readers don't know what the acronym means, spelling it out isn't going to enlighten them. Consider:

This car includes an amplitude modulation/frequency modulation radio.

The camera stores up to 1000 photos in Joint Photographic Experts Group or Portable Network Graphics format.

You can plug any universal serial bus device into the hub.

The store stocks movies on Video Home System tapes and on digital versatile discs.

Perhaps you can see that spelling out what AM/FM or JPEG or PNG or USB or VHS or DVD stands for tells you almost nothing. In these cases, the meaning of the acronym is not what the words stand for. What an uninformed reader needs here is not for the terms to be spelled out, but simply defined.  This might be clearer if you see it with words that started life as acronyms:

I recently got my certification to go self-contained underwater breathing apparatus diving.

The weather reports have certainly gotten more interesting since they introduced color radio detection and ranging.

It's hilarious to tease the cat by shining a light amplification by stimulated emission of radiation pointer around the room.

Does spelling out these acronyms really help? I say no.

When acronyms become loosed from their constituent word-parts and start becoming words in their own right, interesting linguistic things occur. One such hiccup is the famous problem of acronym redundancy (famous in editorial circles, anyway). Here are the examples you'll see most often:

• AC or DC current (alternating current, direct current)
• ATM machine (automatic teller machine)
• FTP protocol (file transfer protocol)
• GIF format (graphics interchange format)
• HIV virus (human immunodeficiency virus)
• PIN number (personal identification number)

(A wit once coined the term RAS syndrome to refer to the use of acronym redundancy, where RAS stands for redundant acronym syndrome.)

Some of these acronyms can function as words but still retain their acronymic sense, but in some cases adding a noun seems inexorable. Thus it's reasonable for someone to say the unredundant I have to stop by the ATM or I forgot my PIN, but I doubt you'll ever hear anyone say The image is in GIF.

As a final note, it would be remiss not to mention the entertaining class of recursive acronyms. A famous example in computer circles is the operating system developed by the Free Software Foundation that is a "work-alike" for Unix. This was playfully named GNU, which stands for "GNU's not Unix." Another example is the programming language named PHP. This originally stood for "Personal Home Page," because it was designed as a way to enhance the capabilities of HTML pages for personal websites. However, PHP has long since outstripped this modest functionality, and the PHP Group now officially says that PHP stands for "PHP: Hypertext Preprocessor." For these types of acronyms, should one ever have the opportunity to define them, it seems like it would be mandatory to spell them out, if only for the amusement value.

Guidelines for acronyms should probably say that if it's helpful to spell it out, spell it out — unless doing so would likely irritate the reader. But before you spell out an acronym, give a thought to whether doing so is actually helpful. If it isn't, consider defining it instead. In other words, and as with most editorial rules, the real guideline is just "do what's right for the reader."