Friendship is a checksum
Colin Steele, on the difficulties of communicating what you mean:
Meaning is heavy stuff. And, as it turns out, difficult to transmit using language. Why? Because language (words) sits one level of indirection away from the models themselves. Follow me, here.
We have the thing itself. We’ll stick with “apple”. Out there, somewhere, is the apple we’re talking about. Then, one level removed from that, are the sensory experiences associated with that apple. (Level of indirection: 1). Aggregated in your head is that sensory input, memories, associations, etc — the mental model of that apple. (Indirection now 2.) Then there is the word I slap onto that model – “apple”. Note that the word represents the model, but isn’t the model itself. (Indirection: 3.) Phew. We’re three hops from the damn piece of fruit, and just getting rolling…
Now I try to talk about the apple. I use the word apple, and a bunch of other words that are intended to connect the dots – make the same associations for your version of “apple” as I have attached to mine. Again, add a level of indirection. (4.) You aggregate into your “apple” model. (5.) You slap the word “apple” on that model. (6.)
Yep. That’s lossy. Your copy of the “apple” model that I’ve tried to convey to you sits about 6 hops away from the thing itself. Maybe more, I’m not sure. And there are no checksums.
That nicely sums up the way that meaning gets lost as it moves from one person to another. Colin then suggests that storytelling is the most effective tool to protect against meaning-loss, and the most compressed version of a story is a metaphor:
Then, invent a defining, central story. A system metaphor captures the essence of the system in the most effective communication tool we have – the story.
This suggests to me the importance of having relationships that last a while. Friendship (or at least prolonged exposure to someone) acts as a kind of checksum. What is a checksum after all, but a pattern whose presence we’ve learned to expect? With old friends, we look for that pattern, we check what they are saying right now against the pattern we’ve seen in the past. If you try to tell me about an apple, and if we’ve known each other awhile, then I’ve all our previous conversations to refer back to. I can recall the conversations we’ve had about pears, grapes and oranges. Possibly I might remember that you prefer tart fruit to sweet, so I know your apple is probably more of a macoun and less of a mutsu – our previous conversations help me narrow down what kind of apple you mean.
This has an interesting implication for work, especially web development. It suggests areas where hiring freelance workers is perhaps inappropriate. To the extent that hiring freelance workers suggests loose, impermanent relationships, then freelancers are a bad choice for startups. Since long relationships make it slightly easier to communicate meaning, and since startups must wrestle constantly with defining their aims and goals, then startups are probably the kind of environment that should prefer long term workers instead of freelancers.
One other thing that this brings up, Colin is partly talking about the illusion of agreement.
Whenever this issue comes up, I’m reminded of 37 Signals philosophy of getting real. In terms of web work, getting real means that you should work with images, rather than functional specs:
Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.
Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” and we think the goal up front should be getting to “no.” Functional specs lead to scope creep from the very start. There’s very little cost in saying “yeah, ok, let’s add that” to a Word document.
As much as possible, you want to make your product real, as fast as possible, so that people in your company can argue over the actual thing, rather than their different conceptions of what that thing should be. If you have the time to build a simple prototype, you should do so. It is true, of course, that in a literal sense “there are no checksums” when 2 people are trying to communicate complex ideas to one another about what direction a software project should take. But there are ways to create checks, to ground the conversation as close to reality as possible, and images of how the software should look on screen is a good one. And simple prototypes of the interface is another good one. 2 people can go very far astray when they argue over words in a document, but when they are looking at an image of the interface, the image helps limit the number of places they can misunderstand each other.