Whether you're producing analytics outputs or reviewing the results, you want to economize your efforts. You want to use the most concise and efficient code but still have the maximum information for understanding.
George Zipf, a linguist and a mathematical sociologist, identified this dynamic in his principle of least effort, which says that, in situations allowing alternatives, people choose the procedures that result in the least average rate of probable work. In data communications, bytes are bundled/coded into packets to minimize the amount of information the sender pushes through a channel. The receiver then must unbundle/decode that packet, so it can verify and validate the information with minimal effort. In presentations, it's not unusual to have speakers use a lot of acronyms: RUP, JAD, and SDLC. They do so to minimize the effort involved in saying "rationale unified process," "joint application development," and "system development life cycle." During the Q&A, audience members often ask the speakers to explain the acronyms.
As for analytics, if you're a coder who insists on minimizing code (because, for coders, nothing exists beyond efficiency and elegance), you should maximize internal documentation/comments and end-user/technical documentation. Keeping your code logic wrapped up in a shroud of mystery may make the program execute faster -- and be your way of assuring job security -- but you have to make it easy for someone to understand your stuff, in case you become unavailable for explanations.
Process diagrams are one way of bringing balance to the Force between analytic authors and audiences. These diagrams can be effective because seeing the paths of black box (inputs and outputs) and white box (detailed view of the data transformation steps) eliminates the struggle between those who want to say less and those who need to hear more. Though a complex diagram carries the risk of being too busy, it still makes it easier for analysts to express and the audience to understand vis-ŗ-vis words alone.
Where possible, I recommend starting out with a diagrammatic representation and then presenting text/code. When visual common ground is established, the senders and receivers will be less likely to get angry with each other because the words became lost in translation.
Sometimes I am ROFL when I see acronyms used as boundary maintenance mechanisms by the self-described cognoscenti and the analytics intelligentsia. The attempt to confuse your audience with esoteric abbreviations and terms can escalate the perception of your IQ and discourage others from asking questions.
BTW, what do you think? Does Zipf's theory mean that people -- senders and receivers -- are basically lazy? Can analysts communicate clearly with those in the C-suite? WDYT?