People are communicating beings

I ran into this older article from Alistair Cockburn the other day called Characterizing people as non-linear, first-order components in software development.

What Dr. Cockburn is talking about, is that very agile of ideas that people are the central focus for any software development effort. Developing software is not just a sausage factory of requirement documents, source code documents, and unit test plan documents. The people are what is important, not the documents.

Deep within it is a fantastic section called "People are communicating beings". In it, Dr. Cockburn says that "The most significant single factor is 'communication'", and presents an informal chart of the efficiency of communication that he uses to "inform my methodological considerations":

This chart shows that real-time, face to face communications is the most efficient. Conversely, written documents are the least efficient format.

The article goes on to say:

If this model is useful, it should inform us as to how better to work. Indeed it does, and we find the busiest projects making use of those suggestions.

'Put all the people into one room.' 'Don't give me more than 4 people, that's all I can get into one room and talking together.' These are standard recommendations of successful project leaders. They plan on using the highest communication mode, people face-to-face...'Make sure there are whiteboards and coffee corners all over the building.' Hewlett-Packard and IBM were early to observe the effectiveness of informal meeting places, and by now it has become a standard idiom in our industry that an effective design environment actively encourage and permit ad hoc meetings of small groups. Weinberg documented specific instances where casual conversations had significant effect on the overall group output [Wei]. Much progress comes when people 'just talk together.'.

A colleague of mine argued on behalf of written documents, and in his case, he took a very conventional view and insisted that the documents were the most important thing to "provide a record of what happened". Dr. Cockburn does not dismiss the need, and addresses this in an excellent manner:

The above model also allows us to make a recommendation for archival documentation:

Have the designer give a short (5-20 minute) description of the design to one or two colleagues who are not familiar with the work. They will act as ombudsmen for the viewers of the videotape. Let the people simply have a discussion of the design, with the colleagues asking questions as they need. Video the discussion. At the end, produce drawings of the examples used in the discussion, or the design drawings used, to act as mnemonic anchors of the discussion.

I was pleased to hear from Lizette Velasquez of Lucent Technologies that not only had she profitably already used that technique, but that I had forgotten to mention something important. She said it is also important to mark and index places where 'something interesting happened'. While much of the discussion proceeds at a relatively slow pace, occasionally a question triggers a flurry of significant discussion, and the viewers will want to refer back to those sections.

These days, it is possible to put the talk online with hyperlinked media.

For those who still think a book is best, consider the excellent but difficult book Design Patterns. Imagine that instead of trying to extract the meaning of the 'Decorator' pattern from the paper, you could click on the page and see one of the authors explaining the pattern in a video clip. They would, of course, rely on tonal inflections, gestures, and timing to get the idea across.

The lesson of this human characteristic is that we should try to move team communications up the curve as far as possible, given the situation at hand.

As I said, Dr. Cockburn does not dismiss the need for archival documentation, he just puts it in its place. Thank you, Doctor! I'm just glad I have some of your wisdom on video.