Day 3: Ward Cunningham: "Trust me, I am not a bozo, I am worth your time"

(Wiki creator Ward Cunningham delivered the keynote Wednesday afternoon at EclipseCon 2006 titled "Software Creativity The Wiki Way".)
 

Ward: I love programming. I'd even like to preserve the word, "programming". To me "programming" is the art and craft of reasoning about the future. You write down what's going to happen in the future (when the code is run). I wasn't around to program on the earliest computers but I was around to touch them. If you haven't been to the Computer History Museum, it's worth the trip. (This was located relatively close to the convention center but I didn't get a chance to go there. --Ed)

Going back to one thing I learned in my high school days was when the computer I was using came with a manual on how to learn computer programming. Halfway through my working on it, the second manual showed up, showing how it all works. I'd learned from the first manual how to write an "if" statement. But in the second manual, I had an "aha" moment, about how there was interchangeability of all the parts. The language of computers is systematic and generative. The leap was from problems to be solved by a computer / statements that will solve those problems to an unbounded world of things that can be created by combinations of statements.

At one time when the telegraph was king, the morse operators were the "cool guys" like web engineers at the peak of the dotcom bubble. Originally it was designed to be printed, but the paper jammed a lot, so the operators learned they could understand it just by listening, through sound alone. I wrote a program that would teach morse code the same way using a feedback teaching method. Even today it has 30 downloads/day.
http://c2.com/morse

Figure 1: The first "dual core" processor. Programming hasn't changed that much since then, but who I do it with has changed:

• 60's: "me"
• 70's: "us"
• 80's: "you"
• 90's: "we"
• 00's: "all"

In "we" programming, developers play to each other's strengths and trust others to know our weaknesses (e.g., extreme programming). A group of people that believed in that style wrote the "Agile Manifesto" (http://agilemanifesto.org). People endorse it by signing the page, and it's still getting as many signatures as ever.

A model I have for how our industry produces, esp. going forward, is that we produce ideas. The way we produce is is through collaboration, and collaboration is based on a community. The "we" style covers ideas and collaboration but we want to take that level of productivity and expand it into larger and larger groups of people. After all, the innovation comes from the people.

I'm not alone in thinking that this is the future. Strategic assets are more about the creation of ideas and trust more than anything. A lot of people come up to me and want to talk about community. They fall into several groups:

• People who want to sell something and want to create a "buzz"
• People who are tired of maintaining something and hope a community will take over where they left off
• People who are making something that can't be made any other way.

I'm mainly interested in the last category. An example of this is the development over the centuries of natural languages (i.e., human speech and writing). The whole process by which we created something as rich as a natural language couldn't be done any other way.

There's a number of interesting relationships that people can take with respect to each other:

Competition, which makes us work harder.
Cooperation, which lets us share work (instead of duplicate it) and specialize.
Collaboration, which is like aligning mutual interests.

Competition and Collaboration have self organizing properties. Collaboration lets us do for others in ways they might not even know. It's based on trust. A good analogy would be a successful marriage - you don't try to figure out who's carrying out the trash more, you just do it when you see it needs to be done.

When you deal with something as complicated as software you can't write down everything that's going to happen. you can't measure knowledge like you can measure material, This is something that companies are finally beginning to understand. You can measure pounds of steel but you can't measure innovation.

My vision of Eclipse projects are as a place where, in a competitive world, both the consumers and producers of frameworks can collaborate and lead user innovation.

The "Collaborator's Pledge" defines how people work with other people in this world.

You have to trust me. I'm going to do things for you and I'm not telling you how but trust me.
I'm not a bozo. I've got something to offer and I've taken the time to understand what's going on.
I am worth your time. (the Cooperation model would say 'I'm worth your money').

Trust ala wiki makes writing more like programming. You hyperlink to elaborations, refactor for systematic abstraction, allow people to change each others words, watch other people's recent changes (this helps build trust relationships over the net), and so forth.

A wiki also serves the role of "public art". By that I mean, after experiencing it, it changes the way you think. After spending some time there you realize there's this thing going on about trust and community and so forth that you need to come to grips with. This is what I think is most important about wiki. With wikipedia, the whole world is trying to come to grips with this experience.

"Would you believe me if I wrote that WikiWikiWeb changed my life? Well, believe it!-- Don Oleson

Sometimes you have to trust people more than you expect if you want to make something big together. More than you have any reason to expect. We do this all the time, e.g., when deciding if you should open source a code module. It's an act of faith.

When i first wrote the WikiWikiWeb it was about 500 lines of code. We had a contest to see who could write the smallest wiki. So somebody wrote one in 100 lines, and somebody else came back with a 50 line version, and so forth. Eventually the 5 line wiki was developed. 

 

We should be programming works of public art, to look at and experience, i.e., something small that carries a message. For example, CRC-Cards that allocate responsibilities (as opposed to putting things into categories)changed the topic of conversation in the OO community. JUnit says have confidence to make the changes you know you need to make in your program (previously you might have put them off due to fear). Wiki says trust widely to cooperate. The Refactoring Menu says make your code easier to read.

Of course, the guys with the money don't care if it's easy to read, they just care if it works. What they don't realize is that if it's easier to read then it's easy to modify, and it becomes sustainable.

I'm working with Bjorn now, and Jacko - we're out here to help make this grand adventure work. This is our formula for communicating profound ideas:

• A bit of Technology,
• A bit of Methodology, and
• A bit of Community.

Blend together and serve. This formula comes from my experience, and my love of programming. What's good about it is that it produces things busy people can look at and decide to process or not without a lot of work.

Current "Art Projects" include:

Experience Guides. We want to go back and find the "aha moments". It's for advanced, Eclipse-specific topics. There's a coaching network for each guide, and recognition for completion. For example, how many people really "get" IAdaptable? We can help lead people through an experience. It goes back to the idea of the pledge, "trust me, I'm not a bozo".

Eclipse Monkey (a takeoff of grease monkey, a popular plug-in to Mozilla). You don't have to program it because there's a community that creates them and passes them around.

Eclipse Monkey is mostly working now. We took a scripting engine and put it in Eclipse. We're trying to regularize and propagate good procedures between committers. It's a community of practice, and also a shortcut to learning and improving the APIs of every Eclipse project. The style of programming in Eclipse is amazingly versatile but it involves talking to a lot of different objects and APIs. In the scripting world there should be a style where you just say what you want to do and the language will do it.

Scripts like to travel quickly, so we added some menu items like Copy for publication (as email, bugzilla, wiki, or blogger). The person on the other end uses the Monkey > Paste New Script command. Because we wrap it with some funny words you can find them easily on Google by searching for "came wiffling through the eclipsey wood". (Now I guess you can find this page that way too. --Ed)

To aid scripting against a lot of different objects, we created this notion called DOMs (Document Object Models). In the script you reference the DOM by URL. To find out more about Eclipse Monkey go to http://www.eclipse.org/dash to Get Monkey, or tune into our regular chat on Tuesday mornings at 10am pst. Friends of Eclipse Monkey currently include Wayne Beaton (RCP apps in script), Werner Schuster (DOMs in EclipseShell), Patric Mueller (ScriptLoader), and many others.

Take-away quote: "My computer came with wiki pre-installed, they just left out the 5 line config file."