Defensive Programming vs. Defensive Communication
An imperfect but potentially helpful metaphor is to think of Defensive Communication as a variant of Defensive Programming. When collecting and processing data to build charts on our computer (or tablet; or phone), we may encounter various errors for which we can (and should!) prepare ourselves in advance. If something unexpected happens then we can set up an alert so that we are informed of it right away:
try:
plot(my_data)
except:
print(“Something went wrong. Go back and troubleshoot.”)
Unfortunately, we cannot program a similar feedback loop when we share our analyses with others. Unlike computer programs, people will not communicate their feedback unconditionally, and we may never learn that our charts - which we thought were great - actually did not make any sense to them, or prompted them to draw a completely different set of conclusions than the ones we expected:
try:
Here is my chart. The patterns and conclusions are obvious: A, B and C.
except:
There is no automatic “except” when communicating (I wish). Nobody may tell you anything.
Real Outcomes:
I don’t understand a thing. Looks very confusing. Whatever
Aha, so this plot indicates D, E and F.
The colors are very nice, and the format is professional. Excellent
It’s pretty clear you don’t know anything about visualizing data.
Your data looks wrong. You probably screwed things up, big time.
What should I have for lunch?
Defensive Communication techniques
In the absence of an automatic feedback loop informing us when our charts were not read and understood as expected, we can implement a two-step process to try to prevent and mitigate the misunderstandings that, in the long run, are unavoidable:
- Share your output and ask for feedback proactively. Repeated interactions with a number of colleagues and readers should allow one to assemble a set of guidelines for how to produce and customize charts so that they gradually become more helpful and less likely to be misinterpreted. Pay very close attention to the questions that you receive: those can be a gold mine for better understanding what can be confusing and what is not.
- Set up an imaginary feedback loop in your mind, based on the actual feedback received at step #1. Others may not want or bother to share their opinions freely (how many times did you hear that your chart is a piece of garbage? haha) - but one can always make up What-If scenarios and criticize oneself. Try to imagine everything that could go wrong: as they say, chances are that it will.
Another key feature of Defensive Programming that is applicable to Defensive Communication is redundancy. Similar to how we should write robust, redundant programs that anticipate the ways in which things could go wrong (sometimes it takes a whole suite of checks just to see exactly how an error occurred), we should also prepare ourselves in advance against the ways in which our charts could be misunderstood. In many cases, that means that we should repeat the same information multiple times, in different ways and different places, even at the risk of annoying some readers. Rather than considering those cases annoying or unnecessary, we may gradually begin to appreciate their role as providing insurance against the possibility of undesired outcomes (such as incorrect conclusions).
Easy to Read, yet Hard to Misunderstand
This is easy to write but probably hard to do. Even better, these requirements contradict each other to some extent. Make charts very easy to read and they might be misunderstood. Add more details to prevent incorrect conclusions, and nobody may want to read them any more. Simplify them too much, and they might become misleading again.
What to do? There is likely no algorithmic way out of here, but specific examples of the kind that we will see on this blog can help. As always, the context is very important (data, findings, medium, audience, objectives, etc.), and I don’t mean to offer suggestions that are supposed to always work.