That little grimace What is the information content of a raised eyebrow? Don't look for the answer in Claude Shannon's seminal papers about information theory (Shannon 1963). He analyzed constrained channels, those in which the communication vocabulary is known in advance. In real-world communication, the channel is unconstrained. When or whether you raise your eyebrow is not prearranged. The "stiffening of your top lip" is the invention of a moment, referencing a shared experience with your conversation partner. In the poem above, the partner had that shared experience but the spotter did not. And so the spotter did not derive the same information content as the partner. Biologists Maturana and Varela have investigated this in the context of biological systems. The following wording from The Tree of Knowledge (Maturana 1998, p. 196) describes their results:
To put it into words that are simpler, although perhaps less accurate biologically, each living being exists inside a membrane that transfers impinging events into internal signals, which initiate internal activities. It is really only the internal signals that the being "notices," not the external signals. The surprising thing is that the internal signals can also be generated by activities and events inside the being! A being that "notices" something cannot be sure whether that something originated from an internal or external signal. Thus we "see" images in dreams and hallucinations, when the eyes are closed. Maturana and Varela studied this effect in color vision, finding that we regularly see a color in a scene that does not explicitly contain that color. We generate the color's presence through internal mechanisms. The "behavioral coordination in a realm of structural coupling" is the correlation between those things impinging on the membrane from the outside and the internal activities that follow. Obviously, we wouldn't last very long as beings if there weren't a fairly good correlation between the outside events and the internal activities generated. It is important to recognize, however, that the internal activities are equally determined by the internal state of the being, its "own structural determination." The information received is not what impinges upon the receiver, but what happens inside the receiver afterwards. To put this into a concrete example, suppose someone runs into the room and shouts "Fire!" in Japanese. A Japanese-speaking listener receives a lot of information and immediately leaps up and runs to the exit. The Japanese person next to him, who happens to be asleep, receives no information at all. The external stimulus was never converted into an internal signal. A person who speaks no Japanese notices that someone came in and shouted something, but he received no particular information from the sounds uttered. What each person receives from the shout depends on his internal condition. Internal RestructuringInformation at the receiver's side is not a static, externally determinable quantity but rather a transient, dynamic personal quantity. The information received is a measure of the internal restructuring that follows the impingement of the signal. It is the quantity representing the size of the change in the receiver's predictive model of the world after receiving it. Consider these few examples to see this in action:
At this point the listener has built up a predictive model that holds those numbers, the fact that they are in the set, and that 5 and 9 are conspicuously missing. They are conspicuously missing because the typical person constructed a second model, "the odd numbers without 5 and 9," alongside the first. The speaker continues with:
On hearing this, the model grows by one element, that "15 is in the set." No new patterns show up. The speaker continues with:
At this point, the model changes dramatically, because the sentence contained a lot of "information" for the listener, much more than the earlier arrival of the number 15. Instead of adding two more to the list of numbers in the set, the listener reduces the model to be "the odd numbers." Hearing that 5 and 9 are in the set added more than two small units of information: It converted two medium-sized, competing models into a single, small model. The change in the size of the predictive model was relatively large. The "information received," being a measure of the momentary change in the receiver, is a transient quantity. Hearing the same sentence twice does not bring the same information the second time. Typically, the receiver's internal predictive model does not change as much, because the restructuring is usually smaller. Suppose the speaker repeats,
The listener already knows that 5 and 9 are in the set. At this point, the speaker can keep naming odd numbers without disturbing the predictive model of the listener. Each new number adds increasing certainty about the model, but not much more. If the speaker names an even number, then the listener scrambles to recall which odd numbers were named. He must throw away the "odd numbers" model and remember each number individually again. The moment of adding an even number provides a lot of information for the listener. Touching into Shared ExperienceHow do you ever know what message your listener receives? In conversation he returns messages, and you convince yourself that he really understood your intended message (at least closely enough). Of course, sometimes you misunderstand his return message and falsely conclude that he understood your message. When you eventually find out, you exclaim, "But I thought my message was clear!" The success of communication, then, lies in the sender and receiver having a shared experience to refer to.
When you have an experience sufficiently in common with another person, all you need to do is re-evoke that experience within him. When you touch a second experience in close succession, you link the two, creating new information. The fact of considering those two experiences as relevant to the moment is a new, shared experience for the two of you, one that you can later refer to. In this way, people jointly construct new concepts a little at a time, building new touch points from known experiences. Someone joining in at the end of the conversation lacks those intermediate touch points and must be "brought up to speed"; that is, given sufficient touch points to join in. These touch points grow as a person progresses in experience from beginner to junior, expert, and eventually working partner. Beginners attend a programming school, where they pick up an initial vocabulary on which to build. They learn standardized notations and simple idioms, which create touch points for the low-level elements of design. Those who are learning object-oriented design become familiar with subclassing and polymorphism at the early stages, sequence charts and cardinality soon after, and perhaps a few of the Design Patterns (Gamma 1995). An experienced person trying to communicate a design to someone with this background can only work from these low-level terms. The experienced designer typically experiences this as tedious and missing the overall intention behind the design. A junior programmer joins a series of projects, building common vocabulary and ideas in stages. The experienced person describing a design to a person at this stage might review some source code, do some joint programming, role-play the operation with some index cards, draw UML diagrams of various kinds, and draw arbitrary scribbles on the whiteboard while talking. The experienced person helps build a different vocabulary in the junior person, and the two of them create new experience they can later refer to. Two experienced programmers who have not been on projects together refer to common, advanced idioms of design. Their conversation might include fragments such as ". . . Just use Composite here, with a Decorator for the side view," ". . . Set them up as dot-h files, but incorporate . . ." and so on. Through these large elements of description and additional squiggles on the whiteboard, one can convey an understanding of the design structure and perhaps reach the intention of the design. Programmers who have worked together for years have many touch points of shared experience. Their descriptions of requirements and design can be very brief, built on references to previous projects. ". . . It's the same pseudo-DNA structure we used on the Fox project, but this time separating out the . . ." The shortcut expressions allow them to communicate and move at a speed not possible with even advanced outsiders. They convey much better the intentions they had while designing. In professional life, people don't have time to rebuild the vocabulary from the ground up each time they need to communicate. They look for the highest level of common experience they share and build new experiences from there. In no case can they ever be sure the listener really understands what was intended. Managing Imperfect CommunicationCommunication is never perfect and complete. Such a thing is not even possible. Even assuming for the moment that you, yourself, know what you intend, the receivers of the communication must jump across a gap at some point and must jump it all on their own. People with similar experience can jump a large gap, working even from mumblings and gestures. The more different another person is from you, the smaller the communication gap that he can jump. You have to back up, explain basic concepts, and then work forward until he builds his own bridge of experience and understands what you are saying. There is no end to this backing up. No matter how much you back up, there is always someone who will not understand. The irony is apparent: In the computer industry, we write specification and design documents as though we can actually explain what we mean. We can't. We can never hope to completely specify the requirements or the design. We have to assume that the reader has a certain level of experience. If we can assume more experience, then we can write less. If we have to assume less experience, then we have to write more.
The domain expert could jump the large gap presented by the short use case document and then produce, as needed, and only as needed, communication to fill in and reduce the size of the gaps so that the Russian programmers could jump across. The domain expert did not attempt to communicate perfectly. He managed the continuous incompleteness of the communications by interacting with the programmers in person and watching what they produced. Luke Hohmann (1997) refers to this as "reducing the equivocality" in the communication. What the domain expert understood was that he did not have to reduce the equivocality to zero. He only had to reduce it to the point that the Russian programmers could take meaningful action. Given that complete communication is never possible, the task on a project is not to try for complete communication but to manage the incompleteness of our communications. The target is to reduce equivocality enough for appropriate action to be taken. That means guessing how much is needed, where to stop, when and how to make the gaps smaller, and how to help the receivers jump larger gaps. Software projects are short on time and money, and making the gap smaller costs both. You need to discover how large a gap you can get by with at each moment, how much equivocality you can tolerate, and stop there. |