Perusing /. as I normally do netted me this article about how 'IT' jargon disrupts the workplace. The LabVIEW style guide we follow has a strict 'no jargon' policy. For example, we are expected to define acronyms on their first usage in a help topic or PDF manual chapter. For the Control Design & Sim documentation, I define terms like single-input single-output (SISO), multiple-input multiple-output (MIMO), linear time-invariant (LTI), and other acronyms fairly regularly. It gets a bit tedious, but the thought and concept behind the guideline is sound. We can't all be control systems designers :-)
Stepping outside of your own mind is hard to do. After writing and editing Control Design documentation for so long, I wouldn't consider LTI to be an acronym worth defining every topic. But the next person who reads the manual might be a complete newcomer, or they might come from an industry where LTI means something else entirely. So it's just become a reflex I try to engage while editing a document: did I already define that acronym in this topic/chapter?
Our style guide lists acronyms we don't have to define. These include CPU, RAM, DLL, TCP/IP, etc. These also include acronyms related to NI products like PXI, DAQ, and GPIB. For what it's worth, I think DAQ is a great acronym.
Of course, it's not just acronyms: terms like "rate-monotonic scheduling" and "positive semi-definite" occur quite frequently in the CD & Sim documentation. What's the Boltzmann constant? In these instances, it's up to a developer to tell me if the term is industry standard or not. Can we expect customers purchasing this product to be familiar with these terms? I certainly didn't know what they meant when I first heard them. Unless I hear otherwise, I'm expected to define them, which I think is a good policy. You never know who will be reading your documentation.
Also, I discovered that my blog is #4 on Google's Blog Search for "LabVIEW." Joel Sumner occupies the top two spots. I guess this means people are reading our blogs! :-) I'm going to try and read and link to more technical writing blogs to get this address out to more people.