Development As Conversation

I recently used a conversation metaphor as partial explanation for why my pattern language for competitive development (Episodes) doesn't yet discuss how to get started...

Often a conversation wanders a bit until the participants connect with each other. Then they can advance positions based on statements made only moments ago. Episodes considers software development to be a long conversation. I've only written the patterns that apply after the developers have "connected". -- WardCunningham

This is a good way of putting it. Connecting can happen in different ways and speeds on a per team and per project basis. -- PatrickLogan

It is not just a metaphor. It is the process. When you bring a bunch together for a purpose they cannot collaborate toward the purpose until they learn to communicate with each other. PeterSenge stresses the importance of dialog (from the Latin for "meaning moving through") as a skill in knowledge workers. Part of the language they will eventually adopt comes with them. A smaller, but critical, part will be co-evolved in situ. This part is the names of things: a pattern here, a pattern there, a data element defined, a subsystem named, roles and responsibilities decided, etc.

One measure of a project plan is the degree to which it provides for the development of the team's ontology.

Also, as we discussed in Seattle, this is why good development teams always have big charts on the shared wall that show the "privileged words" and schemas that all must honor. We used to bury that information in Programmer's Guides which got compiled and published about 65 days after they were needed. That is why 70% of bugs discovered in System Test were traced to interface misunderstandings.

{We can substantiate these numbers from fairly rigorous studies in AT&T -- JimCoplien}

Documentation of the design is important. In fact, I did a paper, circa 1979, that showed the amount of information that must flow through a software development team is two times to three times what must be published to the customer, even if you do an excellent job of customer documentation. The key, of course is on-line documentation with hyperlinks. -- JackRing

No, the key is not on-line anything. Tools, no matter how good, will not solve the problem. The key is getting developers to talk to each other, the architects, and the customers. Web or hyper-linked documentation is a good idea for finding WHO to talk to, or for answering "simple" questions, but the fact is that the harder, deeper issues never get answered on paper. This goes back to the FallacyOfOmniscientDesign. -- KyleBrown

Ditto. And having the proper organization structure is central to proper dialogue.

KentBeck notes: "Communication is the problem of software development" (don't remember where he said this, but I remember it was him).
And Senge notes: "Hierarchy is antithetical to dialogue."
A former CEO or other illustrious person at AutoDesk is noted to have said: "Bad companies have position statements; good companies have dialogue."

A panel at OopslaInSanJose will be addressing this issue: see http://192.20.225.101/orgs/ssr/people/cope/oopsla/CrossingTheChasm.html. Panelists will be

AlistairCockburn,
LeoBrajkovich? (a cultural anthropologist),
JimCoplien, and
LarryConstantine.

One focus of the panel is the question: What mechanisms are required to facilitate communication between cultures of differing maturity?

See also my column titled The Human Side of Patterns in the C++ Report and available at http://www.sigs.com/publications/docs/cppr/9601/cppr9601.c.noname.html. -- JimCoplien

There's often a lot of leverage to be had by making the conversation graphical. The difficulty in making that good connection between people often has to do with the different internal pictures they're painting over the external set of words. Getting people to at least agree on a common picture to disagree about is often a good first step.

-- DaveSmith (7/27/96)

Watching the conversation unfold does help. KirkWolf has tried to envision a development environment that is 3D and retains conversations in their entirety. The power of this I recently encountered and noticed when... I had a long conversation with SteveCook about processes and objects, his suggestions and my experiences with formalized interaction diagrams, counters, etc. It was over lunch, and we went through a bit pile of napkins with our sample situations, sketches, etc. A number of the napkins were empty, but placed on the table as markers of instances of things. When we left, I carefully took all the paper napkins with me, even the empty ones (much to the amusement of those around me).

That afternoon, as fate would have it, someone else brought up the topic of Steve and his current ideas on processes, etc. I pulled out the napkins, and thanks to their stacking, was able to replay the entire conversation, including the necessary placement of the blank ones (they were necessary). Through this, and I am sure it could not have been done without the napkins, our colleague was able to see the full give and take of ideas, counters, and situations. This was a conveying of design that I have not experienced before or since. The conveyance was in the conversation itself - as Plato said: "principles laboriously tested and rubbed one against the other in a reconciliatory tone without ill-will".

I still have the napkins, and I sometimes wonder if I could still manage to get all of the conversation back out of them, even though 6 months have passed. That experience fits this discussion, but I have otherwise not enough imagination to find it the next step of application.

-- AlistairCockburn

Does "GOTO HELL" qualify?