Camp Fire

Problem: Developers are resistant to formal methods of distributing information

Forces:

• Creating formal documentation is to tedious for developers, so they either don't do it, or only put in a token effort and create a useless document.
• Developers are happy to share their information interactively.
• It is not well known who knows what, resulting in wild goose chases for information.

Resolution: Schedule regular meetings whose sole purpose is the transfer of information. These are specifically _not_ status meetings, or problem resolution meetings. There may be (and often is) debate that arises in these meetings, but the initial purpose should be to transfer information, even if it's just "I'm thinking of doing this..."

Comments:

This pattern comes from a quote by DonDwiggens? on mailto:organization-patterns@cs.uiuc.edu:

I've begun to think of many of the software development organizations I've seen as pre-literate cultures, in which the most important knowledge and information is transmitted orally. The problem is, there are no long evenings around the fire singing the songs and telling the stories, so the culture gets transmitted in a haphazard fashion, if at all.

The ensuing discussion covered the transition to a literate society. It struck me that literacy was motivated by the need to communicate something rather than some desire to simply be literate.

I had experienced the pre-literate behavior mentioned above in my own work group at the time. In an attempt to promote communication I instituted a weekly two hour meeting (named a "palaver" to emphasize the informal aspect) to simply exchange designs, idioms and experiences. It was well accepted, and has since been adopted by a number of other groups at my company. (All of these groups are 8-12 people in size.)

One observation is that the formality and dynamic of the meetings varies markedly from group to group, but the campfire feeling of "anyone can discuss anything" is a vital part of all of them. This is consistent with the culture concept mentioned in Don's quote.

An interesting effect of these meetings is that the information communicated in a PaLaver? is often documented by the developer presenting it it after he has had an opportunity to see how well it is received. This seems that the problem is not so much getting a developer to document as it is getting them to communicate.

It is also notable that mailing lists do not seem to provide the same sort of dynamic that makes these meeting successful (Although they do provide a good place to document the results of a meeting).

-- FriedrichKnauss