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?
Kicheko, Discussing code responsibility also opens the discussion with clients as to what it takes to execute an analytics-related project. I am not sure it is a bad thing for one person to manage code if the person undertands the project and its scope for a client. But there is a breaking point where a team needs to be responsible rather than a single source. The need to understand scope is a challenging discussion - some things are unknowns - but it's a worthwhile discussion to set expectations as much as possible.
MNorth - great piece and on target. Like in the Wizard of Oz - 'don't look behind the curtain!' There are sociological and psychological dimensions to analytics - in a nut shell - we are insecure beings - collectively and individually. Hope we can move toward transparency and trust. As in the film - Wizards can be useful even when we are completly open and honest. Until then - its still a 'numbers game'.
Agree wholeheartedly! But in this day, it still happens. This is very risky, but some shops become so comfortable with the flow of activity over a number of years that they forget that sudden and unexpected transitions can happen. Some people want to be the keeper of the secret code and their managers will let them. After all - what could happen????
Brian, - IMO it is always a bad idea to be the single person that knows and understands your code. The best code is written in teams. Even as a customer i wouldn't go for one-man code that is undocumented because when the programmer dies(worst case scenario) or is out of country and we have an emergency, that will be it with that system.
In my piece on the Bowl Championship Series last week, I mentioned that one of the greatest criticisms is that the BCS formula uses computer models that are not open for public scrutiny. The computers analyze the data and spit out these rankings, but no one can determine what happened in the code to decide if the rankings mean anything useful.
The standard IT answer is - 'it depends'. Typically a coder will/should internally document the program (header template with in-line and block comments); but this is assuming that s/he works in a structured environment where there is turn-over and that someone else may maintain the code down the road. In shops where a coder is 'fire-proof', works alone and assumes s/he will stay/live forever, there may not be as much internal coding because the functionality is committed to memory. And as long as you are the only person who understands the code, your job is safe. You protect your knowledge of the code as a Jedi protects a lightsaber.
A coder may also do the end-user or technical documentation, but it depends if this is a small company where the coder does the work of three people, or a company that can afford a business analyst or tech writer. If the company is a contractor, they will have a separate person for external documentation - each additional person represents revenue. If they are smart, they will bill for a business analyst, requirements person, tester and tech writer to create a paper trail outside of the code itself. But beyond the revenue value, it does help to have someone to ensure that the internal and external documentation is useful, usable and used.
Another factor is whether English is the person's primary language. For the sake of revenue enhancement, I have seen staff augmentation with an emphasis on capturing off-shore talent. These employees are not always comfortable writing down comments for fear that their written English skills will expose them or get them labeled as expendable. Hence, being hesitant to provide anything beyond very basic statements does not mean a lack of conscientiousness, but the need to get comfortable in putting one's words in the public square.
Bryan, interesting advice! Do you find that coders are typically writing the document around their work or working with somebody else who can do that for them? I'm thinking a coder might not always be the best person to communicate that info.
LEADERS FROM THE BUSINESS AND IT COMMUNITIES DUEL OVER CRITICAL TECHNOLOGY ISSUES
The Current Discussion
Visual Analytics: Who Carries the Onus? The Issue: Data visualization is an up-and-coming technology for businesses that want to deliver analytical results in a visual way, enabling analysts the ability to spot patterns more easily and business users to absorb the insight at a glance and better understand what questions to ask of the data. But does it make more sense to train everybody to handle the visualization mandate or bring on visualization expertise? Our experts are divided on the question. The Speakers: Hyoun Park, Principal Analyst, Nucleus Research; Jonathan Schwabish, US Economist & Data Visualizer
To save this item to your list of favorite AllAnalytics content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Linda Woolley, CEO, Direct Marketing Association, talks about responsible use of consumer data in marketing and the risk of pending federal legislation.
John Cassara, a former US Treasury special agent and now an industry adviser to SAS, explains why text and social media analytics are the next big thing.
Elizabeth Barth-Thacker, a BI and informatics technology manager at Humana, tells us how her team is creating data transparency and building engagement with the business – with the help of an internal collaboration portal called Humanalytics.
Speaking at SAS Global Forum Executive Conference, Rajeev Kaul, SVP of pricing at OfficeMax, uses a Chinese proverb to explain one of the reasons he's deploying SAS Visual Analytics.
In an All Analytics interview, Mike Cavaretta, technical leader, predictive analytics at Ford Research & Advanced Engineering, shares how big-data is fueling vehicle decisions.
With today's advanced visual analytics tools, you can stream data into memory for real-time processing, provide users the ability to explore and manipulate the data, and bring your data to life for the business.
Dynamic data visualizations let analysts and business users interact with the data, changing variables or drilling down into data points, and see results in a flash. Advance your use of data visualization with tools that support features like auto-charting, explanatory pop-ups, and mobile sharing.
No doubt your enterprise is amassing loads of data for fact-based decision-making. Hand in hand with all that data comes big computational requirements. Can traditional IT infrastructure handle the increasing number and complexity of your analytical work? Probably not, which is why you need a backend rethink. Big data calls for a high-performance analytics infrastructure, as Fern Halper, a partner at the IT consulting and research firm, Hurwitz & Associates, discusses here.
Redbox's bright-red DVD kiosks are all but ubiquitous these days, located in more than 28,000 spots across the country. Jayson Tipp, Redbox VP of Analytics and CRM, provides an insider's look at how the company has accomplished its phenomenal nine-year growth.
InterContinental Hotels Group (IHG), a seven-brand global hotelier, has woven analytics into the fabric of its operations. David Schmitt, director of performance strategy and planning, shares IHG's analytics story and his lessons learned.