Alistair Cockburn - Agile Software Development

The speaker continues with: "... 5 and 9 are in the set...”

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 pile 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 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, "... 5 and 9 are in the set...”

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 got 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 Experience

How do you ever know what message your listener receives? In conversation, she returns messages, and you convince yourself that she really understood your intended message (at least closely enough).

Of course, sometimes you misunderstand her return message and falsely conclude that she 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. Grimace at the Store

Yesterday, when you and I were at the store, I grimaced when the sales clerk made a particular remark. Today, I make the same grimace. Your mind flashes back to the situation with the sales clerk. Comparing the situation at the current moment with that one, you detect commonality and transfer yesterday's emotional state to today's situation. You get my intended meaning, because we share a memory of the grimace.

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 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 touchpoints 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, the 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 are able to 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 Communication

Communication 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 do that 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 she can jump . You have to back up, explain basic concepts, and then work forward until she builds her 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 could actually ever 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 Russian Programmers

A group in an American firm that was contracting their programming to a Russian company contacted me. They wanted me to teach them how to write use cases for Russian programmers who knew neither English nor the domain very well.

I said, "You can't hope to teach them the domain inside the requirements document. First teach them the domain, then write a short requirements document that speaks to someone knowledgeable in the domain." After trying for hours to get me to reveal the secret of communicating across this enormous gap, they finally admitted they had previously (and successfully) worked simply by putting the key people in the same room. They were just hoping that I had a way to communicate the requirements across the ocean perfectly using use cases.

In the end, they improved on my suggestion. They wrote a short requirements document for their local domain experts and then flew one of those experts to Russia to translate, explain, and generally ensure that the programmers were doing the right thing.