Skip to main content

On Messages

Although Shannon's Communication Theory is about transmitting Messages, messages are really encoded Ideas and Concepts, from an Internal Model. Let's break down some of the risks associated with this:

When we construct messages in a conversation, we have to make judgements about what the other person already knows. For example, if I talk to you about a new JDBC Driver, this presumes that you know what JDBC is. The message has a dependency on prior knowledge. Or, when talking to children it's often hard work because they assume that you have knowledge of everything they do.

Communication Risk Threats due to Messages​

Let's look at some message-based threats causing Communication Risks.

1. Theory of Mind and The "Split Brain"​

This is called Theory Of Mind: the appreciation that your knowledge is different to other peoples', and adjusting you messages accordingly. When teaching, this is called The Curse Of Knowledge: teachers have difficulty understanding students' problems because they already understand the subject.

A second, related problem is actually Dependency Risk, which is covered more thoroughly in a later section. Often, to understand a new message, you have to have followed everything up to that point already.

The same dependency risk exists for computer software: if there is replication going on between instances of an application and one of the instances misses some messages, you end up with a "Split Brain" scenario, where later messages can't be processed because they refer to an application state that doesn't exist. For example, a message saying:

Update user 53's surname to 'Jones'

only makes sense if the application has previously processed the message

Create user 53 with surname 'Smith'

2. Misinterpretation​

For people, nothing exists unless we have a name for it. The world is just atoms, but we don't think like this. The name is the thing.

"The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it's just a representation, is it not? So if I had written on my picture “This is a pipe”, I'd have been lying!" - Rene Magritte, of The Treachery of Images

People don't rely on rigorous definitions of abstractions like computers do; we make do with fuzzy definitions of concepts and ideas. We rely on Abstraction to move between the name of a thing and the idea of a thing.

This brings about Misinterpretation: names are not precise, and concepts mean different things to different people. We can't be sure that other people have the same meaning for a name that we have.

So one cost of Abstraction is Communication Risk. While abstraction is a massively powerful technique, it lets the function of a thing hide behind the layers of abstraction and become invisible.

As we saw above, Protocols allow things like the Internet to happen - this is amazing! But the higher level protocols hide the details of the lower ones. HTTP didn't know anything about IP packets, for example.

Abstractions hide detail, then. But when they hide from you the details you need this is called a leaky abstraction. Since all abstractions hide information, they are all potentially leaky.

3. Information Assumed​

Because humans don't always need a complete understanding of a concept to use it, we can often cope with some abstraction or omission in communication and this saves us time when we're talking. It would be painful to have conversations if, say, the other person needed to understand everything about how cars worked in order to discuss cars.

For people, Abstraction is a tool that we can use to refer to other concepts, without necessarily knowing how the concepts work. This divorcing of "what" from "how" is the essence of abstraction and is what makes language useful.

The debt of abstraction comes due when you realise that not being given the details prevents you from reasoning about it effectively. Let's think about this in the context of a project status meeting, for example:

  • Can you be sure that the status update contains all the details you need to know?
  • Is the person giving the update wrong or lying?
  • Do you know enough about the details of what's being discussed in order to make informed decisions about how the project is going?

4. Missing Messages​

Let's consider what happens when, in your program, you create a new function, f:

  • First, by creating f, you have given a piece of functionality a name, which is abstraction.
  • Second, f supplies functionality to clients, so we have created a client-supplier relationship.
  • Third, these parties now need to communicate, and this will require a protocol. In a programming language, this protocol dictates the arguments passed to f and the response back from f.

But something else also happens: by creating f, you are saying “I have this operation, the details of which I won’t mention again, but from now on it’s called f” Suddenly, the implementation of “f” hides and it is working invisibly. Things go on in f that people don’t necessarily understand.

Referring to f is a much simpler job than understanding f, and you can carelessly hide things from yourself with software:

  • Adding a thread to an application that doesn't report whether it worked, failed, or is running out of control and consuming all the cycles of the CPU.
  • Redundancy can increase reliability, but only if you know when servers fail, and fix them quickly. Otherwise, you only see problems when the last server fails.
  • When building a web-service, can you assume that it's working for the users in the way you want it to?

When you build a software service, or even implement a thread, ask yourself: "How will I know next week that this is working properly?" If the answer involves manual work and investigation, then your implementation has just created more Communication Risk.

5. Security and The Man-In-The-Middle​

Although protocols can sometimes handle security features of communication (such as Authentication and preventing man-in-the-middle attacks), trust goes further than this, it is the flip-side of Agency Risk, which we will look at later: can you be sure that the other party in the communication is acting in your best interests?

6. Trust Issues​

Even if the receiver trusts the sender, they may not believe the message. Let's look at some reasons for that:

  • Weltanschauung (World View): the ethics, values and beliefs in the receiver's Internal Model may be incompatible to those from the sender.
  • Relativism is the concept that there are no universal truths. Every truth is from a frame of reference. For example, what constitutes offensive language is dependent on the listener.
  • Psycholinguistics is the study of how humans acquire languages. There are different languages, dialects, and industry dialects. We all understand language in different ways, take different meanings and apply different contexts to the messages.

From the point-of-view of Marketing Communications, choosing the right message is part of the battle. You are also trying to communicate your idea in such a way as to be believed.