ChiliPLoP, Day 2

Today, my workshop began in earnest. My goal for today was to collectively
develop a working definition of collaboration, and I’m happy to say
that we achieved that (see Collab:Collaboration). Tomorrow, we’ll
start exploring patterns in earnest.    (1BW)

I have a great group of participants:    (1BX)

We began the day by introducing ourselves to each other. I asked each
person to relate their best collaborative experience. Most people
found it a difficult question, which jives with my overall
experience. Nevertheless, we managed to get enough out of the stories
for a barebones definition to emerge.    (1C2)

I then sent the participants off to read Chapter 4 of Michael Schrage’s
No More Teams! while I refactored my Dialog Map, captured using
Compendium.
(I’ll post the final map at the end of the conference.)    (1C3)

After lunch, I showed the participants my Dialog Map for the first
time. From that point forward, the map became part of the
conversation (Shared Display). We walked through several scenarios —
some of which had emerged from the earlier discussion — deciding
whether or not they constituted collaboration and why.    (1C4)

Afterwards, I refactored the map again, and we started refining the
definition. The end result is at Collab:Collaboration. I’ll post
more commentary on the patterns mailing list.    (1C5)

Throughout the day, all of us recorded possible patterns on index
cards. We’ll use those as a starting point for our discussion
tomorrow.    (1C6)

Side Notes    (1C7)

I had made my expectations very clear at the beginning of the day: My
goal for the day was to have a working definition of collaboration.
(A pattern Ofra calls Set The Pegs.) So, having accomplished that at
the end of the day, we all were satisfied.    (1C8)

On the way to dinner, I ran into another workshop participant who
asked me how my workshop went. I said, “Great. We defined
collaboration.” He thought I was joking. We had spent the entire day
defining one term, and I was actually happy about that.    (1C9)

This was very much by design, and to be perfectly frank, I was glad
that we managed to come up with something workable by the end of the
day. I am a strong believer in Shared Understanding as a prerequisite
for effective collaboration. I’ve also been influenced by the
MGTaylor process, which suggests that spending about two-thirds of the
allotted time on Shared Understanding and Shared Language and the rest
on the concrete objective is actually more effective than attempting
to spend all of the time on the concrete objective. The reason is
that you are not capable of effectively attacking the concrete
objective without first developing Shared Understanding. The end
result is that you end up trying to solve both problems simultaneously
(and often unconsciously) and up doing both poorly. Additionally,
because you were not realistic with your expectations up-front,
everyone walks away disappointed.    (1CA)

The proof, of course, is in the pudding. It’ll be interesting to see
how my participants feel about our overall productivity by the end of
the day tomorrow.    (1CB)

Earlier that day, I described Blue Oxen Associates to another attendee,
who wondered, how will we make money if we give our pattern language
away? He was actually trying to tactfully ask how we make money,
period. I don’t think he realistically thought that we could make
money selling a “proprietary” pattern language.    (1CC)

My response: The real value is in the experience, not in the text
itself, which without context is simply more information in the
infoglut. If you can gain value from merely reading our material,
outstanding. We give it away to heighten the potential impact.
However, to truly appreciate the research, you need to experience it
firsthand. I see Blue Oxen Associates as a new type of learning
organization, where members learn by experiencing and participating in
what we study and what we learn. The value is in the experience and
in being part of our community, and that’s what we expect people to
pay for.    (1CD)

Finally, in the evening, Jerry Michalski demonstrated The Brain, a
Personal Knowledge Management tool. Sadly, it was late in the evening,
and only a few people saw the demo; tomorrow, I’m going to suggest
that he do it again. I had seen The Brain before, but Jerry’s demo is
particularly compelling because he’s been adding data to it since
1997.    (1CE)

One thing that really comes through with The Brain is how little
semantic richness you need for a tool to be useful. The Brain supports
typed links, but Jerry doesn’t use them. Instead, he uses topical
nodes to relate other nodes. In essence, it’s a barebones graph model
with a great UI, but its utility is tremendous. We don’t have enough
tools like it.    (1CF)

ChiliPLoP Day 1

Yesterday afternoon, I arrived in Phoenix, Arizona for Chili PLoP
2004. I hitched a ride with Ralph Johnson and Joe Yoder to Carefree,
Arizona, and soon found myself at the Lutheran Retreat Center, where the
conference is being held.    (1BJ)

The post-dinner agenda was to discuss the structure of the
conference. Other than the meal schedule (which is strictly
enforced), there is no structure. This is what differentiates
Chili PLoP from Hillside Group‘s other PLoP conferences. The setting is
more relaxed, and the agenda is entirely flexible.    (1BK)

Once we got business out of way, the fun began. There were a lot of
great conversations, and a few of us stayed up late into the night
chatting about everything from Pattern Languages to politics.    (1BL)

Tom Munnecke got the discussion started by asking about the
generativity of Pattern Languages. This is an ongoing beef that Tom
has with Pattern Languages, a misunderstanding that’s important to
clarify.    (1BM)

Tom’s thesis is that society is too problem-centric. For example, our
approach to healthcare is to cure sickness rather than to promote
healthy living. Tom’s GivingSpace project — and the reason he’s here
— is to identify and propagate patterns of uplift. This is a
wonderful effort. It’s related to our work on patterns of
collaboration, and it’s an effort I fully support.    (1BN)

Patterns are often defined as solutions to problems in a context.
Tom’s complaint is about the term “problem”; he think it prevents
patterns from being generative. “Problem” in this context, however,
means, “Something that needs a solution,” not, “Something that is
wrong.” In other words, describing things in terms of problems and
solutions does not necessarily prevent the solution from being
generative.    (1BO)

In fact, Christopher Alexander stresses the importance of identifying
generative patterns. Linda Rising cited an example first described by
Don Olson (and is also discussed in Linda’s book, The Patterns
Handbook
). Beginning skiiers often have a tendency to lean back,
something that will cause them to lose their balance. You could say
that one pattern is, “Don’t Lean Back.” This is not very useful
advice. Leaning back is an instinctive, not conscious action.    (1BP)

Don’s suggested pattern is “Hands In View.” This is a conscious action
you can perform, and the end result is that you lean forward. This is
a great example of a generative pattern.    (1BQ)

Ralph cited a similar example in software development:
qmail. The motivation for qmail was to
build a secure mail server. The approach, however, was not to
identify and fix every security problem. The approach was to design
small, modular programs that were easy to verify as secure. In other
words, security was an emergent property of the software’s design.    (1BR)

Other topics of note:    (1BS)

  • Ralph offered the following advice on naming patterns: Use noun phrases, not verbs.    (1BT)
  • Some patterns are not easily cross-cultural. For example, we talked about The Mexican Wave as a pattern of uplift. (I didn’t know that it was “the Mexican wave”; I thought it was just “the wave.”) Ofra Homsky suggested that Israelis would never do the wave. Joe Yoder said the same about Chicago Bears’ fans. The reasoning was that these fans are culturally noncomformist, and that they would never reach the necessary critical mass of fans in order to get the wave going. Similarly, Ofra explained that in America, when people want to increase their applause, they applaud faster. In Europe, people start applauding in rhythm.    (1BU)
  • Jerry Michalski related a story from Dave Grossman’s book, On Killing. Prior to World War I I, the U.S. military did a study that showed that in previous wars, only 10 percent of American soldiers were shooting to kill. This is because most humans naturally do not want to kill other people. The military reacted by changing its training methods, and by the Vietnam War, that number had increased to 90 percent. The point was that we are capable of changing people’s behaviors through training. The result, however, was not only increased killing efficiency but also the emergence of post-traumatic stress syndrome, which only started appearing after the Korean War, and an increase in the suicide rate among soldiers in wartime. The military had managed to change soldier’s behaviors, but at a terrible psychological cost.    (1BV)

Manifesto Comments, Responses

Many thanks to everyone who’s emailed me or blogged about my manifesto. I’ve received great feedback — lots of kind words and constructive comments — both via email and the blogosphere. Because of the good folks at Slashdot, the piece was widely distributed. The last time something I wrote was Slashdotted, the responses were mostly content-free. This time around, quite a few people there had something reasonably substantial to say.    (1AS)

Where’s The Beef?    (1AT)

The most asked question was, “Where’s the beef?” Krysztof Kowalczyk wrote:    (1AU)

It points out problems, shows some meta-solutions but almost no concrete solutions.    (1AV)

Marc Canter added:    (1AW)

There’s nothing he’s saying that I don’t agree with. I just wish he’d get more specific. Screen shots, Mockups, Design guidelines, Wireframes. APIs. Schemas. We need more Schemas!    (1AX)

The point of my backlinks example is that in many cases, concrete solutions already exist; we just haven’t collectively realized it yet. Collaboration can’t happen until we realize that we’re all working on the same problem. There are initiatives for achieving this Shared Understanding, including our Collaboration Collaboratory and OCSI.    (1AY)

That’s the more technical part of the “beef.” However, there’s a sociological element that has to come first: We have to understand what it means to collaborate, and we have to understand how we collaborate. Again, pockets of understanding exist, although they are mostly isolated from each other. We need to unify that understanding.    (1AZ)

Patterns of Collaboration    (1B0)

Blue Oxen Associates is working on that part of the problem. Our approach is to mine for patterns of effective collaboration and to disseminate these patterns widely via a Pattern Language. We’ve hinted at this objective in previous research reports, and we’re further refining it via additional research and other projects. Tomorrow, I’m heading to Carefree, Arizona for Chili PLoP, where I’ll be leading a workshop on patterns of collaboration.    (1B1)

On Slashdot, Jameth commented:    (1B2)

The manifesto makes grand claims about unifying our collaborative language, but totally understates how difficult this is. The problem usually is that we just do not have a solid model of what can and cannot be done, and we likely never will.    (1B3)

Jameth later added:    (1B4)

Collaboration methods change day-to-day. Sometimes the methods change due to whim, sometimes due to fashion, and sometimes due to technology. Whatever the reason, collaboration methods are hard to nail down reliably.    (1B5)

I’m mostly with Jameth here. If I understated the difficulty of unifying our collaborative language, then I did so in error. It is a tremendous challenge. However, his claim that collaborative methods change day to day is incorrect. Perhaps that’s the case for methods in general, but it’s not the case for effective methods. The problem is that we’ve done a poor job of identifying and sharing these methods. This is exactly the problem we’re trying to address.    (1B6)

Metamodeling    (1B7)

Dorothea Salo wrote:    (1B8)

ARGH! Every time I think the One True DTD business has finally run its course?    (1B9)

…    (1BA)

Tell you what, dear heart. You tell me what the “fundamental constructs” of documents actually are — every document on earth, mind you — and I’ll happily help out with a standard way of expressing ’em.    (1BB)

I absolutely do not believe in this notion of “One True DTD”; in fact, I have spoken adamantly against it in the past. As I explain in the manifesto, the fundamental constructs I’m talking about are graphs. Every document can be expressed as a graph. XML fundamentally relies on this property, as its underlying data model is a graph. The point of my piece is, don’t get too caught up with syntax (although don’t ignore it either); focus on the data model.    (1BC)

A Manifesto for Collaborative Tools

I recently wrote an essay entitled, “A Manifesto for Collaborative Tools.” It outlines a vision for how our tools can and should become more interoperable.    (1AQ)

The article is available both on the web and in the May 2004 issue of Dr. Dobb’s Journal. I’ll also be presenting the paper at SRI‘s Artificial Intelligence Center on Thursday, April 29 at 4pm in Menlo Park, California. The talk is open to the public.    (1AR)

Cool Friends, Cool Work

I have several friends who do very cool things, but have a fairly small presence on the Internet. So, I’m going to do my part to make their presence a bit larger by promoting some of their recent activities here.    (1A9)

I’ve mentioned John Ly’s Canine Cliques before, the premier source of luxury items for your dog. John recently added a new feature that allows you to create personal Web pages for your very special pooch.    (1AA)

Greg Corbett — my roommate for all four years of college and living proof that honest lawyers do exist — recently coauthored an article for Legal Times entitled, “Patent and Antitrust, Happy Together?”.    (1AB)

Finally, Stephanie Schaaf is running for Mountain View City Council. Mountain View residents, check out her platform and vote for her in November!    (1AC)