January 27, 2004

Information Ain't Context-Free

Digitizing Paper Documents In a Chocolate Factory

Here's a story.

In a chocolate factory (I love it!), buyers stored contracts, correspondences, and notes in folders. At some point, management decided that it wanted to move the information contained in these documents onto the corporate intranet for easy access by all. Perfectly rational, and pretty much "the thing to do" these days.

The problem was that those folders were not organized very rationally. For one thing, folders often contained many seemingly unrelated artifacts, including advertising memos, hand-written presentation notes, post-its, and scraps clipped onto letters.

Moreover, many documents had annotations hand-written on them. Most of these annotations were meaningful only to the "owner" of the document; to anyone else, they were pretty much undecipherable. And yet, it was very often the case that the most important information was contained in those annotations.

In such a situation, the commonsense notion that a document speaks for itself begins to completely break down. Documents are not context free. What we cavalierly refer to as a document's "contents" is usually little more than a disorganized network of textual or pictorial cues that help someone recollect concepts she may have once had. For example, a memo may have numerous annotations added to it-things like "=> s. l.", "c.b. w/sr", and so on-which would make little sense to anyone other than the owner of that document. After awhile, the annotations become at least as meaningful as its original contents-in fact, the original memo itself may have long ago faded into irrelevance.

Chocolate factories and buyers aside, this is no less true for so-called substantive documents that describe abstract things like organizational processes and software design. In order to understand these kinds of documents, you already have to be fairly privy to the contextual framework with respect to which those documents make sense. This is why a new team member has to continuously "bug" resident team members to help her decipher what everyone else takes to be clear and straightforward documentation.

Document as Context, Not Content

To say that a document "captures" information reflects a rather naïve Cartesian assumption. Documents may support, but they can never constitute the expertise of team members. Information-- if it exists-- exists in the minds of the people who wrote the documents, and not in the documents themselves. Documents resonate a wider network of activities. When taken outside that network, documents lose their ability to convey information. For this reason, documents cannot speak for themselves.

I propose that we understand a document, not as something which has a content-and is bound exclusively to that content. Rather, I suggest that we understand a document as that which orients a reader to situate herself within a particular interpretive frame. A document sets the stage; it awakens in the reader the requisite mindset for understanding how a particular culture describes its activities, thoughts, attitudes, and feelings. It helps the reader learn a particular set of meta-patterns (cognitive, social, and epistemological) on the basis of which the principles, practices-and even moods-of a particular culture can be comprehended.

Through its ability to orient a reader, a document acclimates her to the sense-making culture of a particular situation. So acclimated, in-person communications (e.g. explanations at the white board, pair-programming) and in-situ communication frames (e.g. unit test suites) have the capacity for providing rapid transfer of technical and business contents.

Take, as an example, Kent Beck's Extreme Programming Explained. What makes this book so great is that, while it purportedly "explains" the principles and practices of XP, what it actually does is to give the reader a flavor for the kinds of meta-patterns that characterize the culture of XP. By using a whole host of language idioms, moods, narrative styles, and inside jokes, Beck succeeds in evoking a particular kind of mindset.

The book, in effect, resonates in a subtle way the kinds of meta-information one needs in order to understand, appreciate, and embrace the engineering principles it describes. Only when one has acculturated oneself to this mindset, does it become possible to begin to understand XP in such a way as to make productive use of its practices in a real situation. As such, Extreme Programming Explained may be the first post-modern software methodology book.

What if we were to approach internal documents this way? Rather than radiating content, they radiate mood and context-that they playfully and seductively tell the stories of the organizations in which we work and into which we invite visitors and newcomers. Suppose, further, we were to think of documents not as containers of information, but as "frameworks" for learning and discovery.

Were we to take such an approach to documentation, we could throw away those huge tomes nobody reads and replace them with comic books, parables, epic poems, and modernist one-acts that could be read aloud and even performed live whenever important information needs to be conveyed.

Posted by mhamman at January 27, 2004 03:15 PM | TrackBack