A Conversation with Ward Cunningham, Part IV

---

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the world's first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.

On September 23, 2003, Bill Venners met with Ward Cunningham at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Cunningham gives insights into wikis and several aspects of Extreme Programming.

• In Part I: Exploring with Wiki, Cunningham discusses using wiki for collaborative exploration and the tradeoff between wiki authors and readers.
• In Part II: Collective Ownership of Code and Text, Cunningham discusses how he designed wiki to be a model for collective code ownership, collective incentives for pride of ownership, and how to deal with disagreements by eliminating the cost of making mistakes.
• In Part III: Working the Program, Cunningham discusses the flattening of the cost of change curve, the problem with predicting the future, and the program as clay in the artist's hand.
• In this fourth installment, Cunningham discusses using the programming language, rather than the whiteboard, to design and communicate ideas.

The Extreme in Extreme Programming

Bill Venners: In Extreme Programming Explained, Kent Beck wrote, "We are traditionally told to plan for the future, to design for reuse. Instead, XP says to do a good job (tests, refactoring, communication) of solving today's job today and trust your ability to add complexity in the future where you need it." It has indeed been my experience that it's hard to predict the future. It's not necessarily just predicting the future that's hard, though, it's understanding the whole problem. At the beginning, you don't understand the problem enough to know what to design. You discover a lot about the problem space by implementing the code. Coding is almost like exploring the space. You discover more and more detailed information about the problem space as you explore it by coding.

On the other hand, I find it a bit extreme that I would never trust my intuition or experience about what I'll need in the future. For example, maybe I don't really need a database right now at the start of a project. I could just use a flat file. But my experience and intuition tells me that it's pretty darn likely I will eventually need a database. I'm not sure why Extreme Programming is called Extreme Programming, but I find the tone of its advice somewhat extreme, including the advice to never implement something unless it is needed today. In practice, to what extent should we "solve today's job today" exclusively? To what extreme should we take that advice?

Ward Cunningham: Honest to God, I think Kent Beck's contribution to all this has been taking stuff that he and I discovered quietly together, or picked up from other programmers, and taking it to the limit. Taking it to the limit. And the fact that it actually holds up—and a lot of it improves—when taking it to the limit is why it should naturally be called "Extreme." Kent's single biggest contribution is being daring enough to say, "This is all that matters, and we should do it all the time."

When history looks back at Extreme Programming, people will probably discover there really was a thirteenth practice that Kent didn't know and one practice that only had to be done eighty percent of the time. But XP is so close, it's startling. It is startling that there is a unity that comes from these practices when you do them to the extreme that is counter-intuitive.

Thinking About Tomorrow, Tomorrow

Bill Venners: Let's look in particular at the question of how far to look ahead. I'll give you a metaphor. Oddly enough, when I first encountered test-driven development, it reminded me of Grandma Moses. When I was a kid, I took oil painting classes from a lady named Flora Yentes. And she taught me to first sketch the image in charcoal, then paint over that with yellow ochre. After that dried, I could rub the charcoal away and have an outline of the painting in yellow ochre paint. Then she had me paint a wash: broad brush strokes with thin paint that fleshed out the general colors and shapes. Finally, once the wash was dry, I painted in the details.

Grandma Moses didn't paint that way. She said, "I paint from the top down. First the sky, then the mountains, then the hills, then the houses, then the cattle, and then the people." She didn't sketch out the big picture then fill in the details. She started at one corner and incrementally painted details across the canvas. Test-driven development reminds me of Grandma Moses's style of painting. Instead of first fleshing out the big picture with some up-front design, I just look at the first piece of functionality. I write a test and implement the code. Then I look at the next piece of functionality, write a test, implement the code, refactor. I repeat that process all the way across the canvas.

I have used a disciplined test-driven approach on several projects, and it has worked well. But I still like to do up-front, big-picture thinking before coding. So in practice, to what extreme should we follow XP's advice to not look ahead?

Ward Cunningham: Here's what really converted Ron Jeffries: Ron knew how much he knew, because he had written every kind of program. He is a dogmatic zealot for XP, because he discovered he could actually produce better code by consciously not thinking about tomorrow. Not that he was going to forget anything he knows. Tomorrow will come soon enough. And tomorrow he'll say, "Now it is time to do this." He'll say, " I'm going to take everything I've learned in the project so far, and everything I knew before this project, and I'm going to make a decision today, because today is finally here."

To worry about tomorrow is to detract from your work today. Time you spend thinking about tomorrow is time you're not spending thinking about what to do today. The place you leave in the code because you think you'll need it tomorrow, is actually a waste of time today—and a liability tomorrow. It does more harm than good.

That doesn't mean that you don't think. You'll find that you have a beautiful opportunity to think tomorrow, because everything is laid out. Tomorrow when you get to that point, where you really do need to use this experience that you have, you'll find that the particulars are right there in front of you. The codebase is ready to take what you're about to write. If a change is required anywhere, you have permission to make it. And at the end of the day you'll see the fruits of applying that knowledge.

The program will be much more receiving of your wisdom tomorrow than it is today, when you would need to tell the story without the aid of a computer. In other words, when I go to the whiteboard and say, "I think this is what we'll need, and this will be enough," I actually have less support in taking my experience and getting it into a design than if I just stay with the project and program it day in and day out. The programming language is a better language than the whiteboard for getting every valuable bit of my experience into a design.

Bill Venners: The programming language?

Ward Cunningham: Yeah, the programming language. Or if we invent a language or a configuration file or the sequence of buttons—whatever we make.

Bill Venners: The artifact.

Ward Cunningham: Right. Many people have experience with a program that's gotten out of control. They have an idea. They think they know what they want to do. But when they go to put the idea in, the idea is forgotten by the time they've figured out how to put it in. They'll just say, "Every time I try to do this, it's like going down a rat hole. I could put it here, but I have to change this thing. To change that thing I have to change this other thing. To change this other thing..." Or they try it and it simply blows up. It's just too hard to change. The program is very brittle. And in that environment they think, "God, I never want to do that again. I want get my ideas out. I'll just write my ideas on paper and I'll let somebody else do that junky work." But it's less effective. If you're really sharp and you have lots of experience, you can bring that experience to bear more easily by just agreeing to never let the program get that brittle.

Refactoring the Mind

Bill Venners: On a recent plane flight I was watching a movie called Possession, in which Gwyneth Paltrow and Aaron Eckhart play two literary scholars. They discover some letters written between a Victorian poet and his up-to-then secret love interest, and read them aloud. These letters were beautifully written, and it made me think about the way technology affects our minds. Letters from the 18th and 19th centuries don't sound like emails. They don't even sound like modern letters. They sound richer and more contemplative then modern correspondance.

In the days before writing, people had to use their memory more. Perhaps their memory was better than ours, because it got more practice. In the 19th century, before the fountain pen, people wrote letters with quills they dipped in ink. If they screwed up at the bottom of the page, they had to write the whole page over again. So they likely thought more before each act of writing than people do now in this age of the backspace key. Back then people planned out more of the text in their head, and kept more of it in their head, before committing it to paper. And I imagine all that practice helped them get good at that kind of thinking.

Extreme Programming's emphasis on refactoring over up-front planning would make little sense outside the context of our current technology. We have a backspace key and the ability to select text. We can copy text, delete it, duplicate it, or move it in a few keystrokes. We also have scripting languages and refactoring IDEs that help us make changes to existing code. These technologies are empowering, but is there a cost? Because we don't need to think ahead as much, we won't practice thinking ahead as much. Will our abilities to think ahead decline?

Ward Cunningham: It may be that we're thinking differently. To say whether that difference is better or worse would be a value judgment that would require looking at a much bigger picture. I was told once that to learn to write a letter, you start writing the letter. If you make a mistake, you set the page aside and you start writing the letter over again. You'll get farther, but you'll make another mistake and you'll start it over again. Eventually you'll get the letter written. If you do this for a week, you change the way you think about the production of words to the point where you tend to write whole sentences, whole paragraphs that just flow from the pen. Nobody says, "Make a master plan for the page. Figure out what paragraphs are going to do." It's more a process of opening machinery in your mind that already does it. The way to practice that is to write letters, and if you make a mistake, write it over again and over again. It is an incremental approach to mastering the use of some capability that is intrinsically human. As I spin word after word out here in conversation, I'm using that same machinery.

In XP, we're saying that for a group of people to work together as a high performance team, they must take information that an individual might be able to manage in the back of his or her mind, and put it on the screen. Once the information is out of an individual mind and on a screen, it is subject to our collective use. And with pair programming, that is reasonably efficient. If you are sitting there, there are enough clues. Pair programming takes an act of creation that could go on in the back of your head if you were programming by yourself, and puts it on the screen where it can be watched. Because it can be watched, it can be shared. Because it can be shared, you get a magnification. Technique flows through the organization that wouldn't flow otherwise—technique about how to think.

By insisting that the bulk of activity happen on the screen, we take an individual activity and make it a collective activity. If I can't tell what you're thinking while I'm watching you type, we're not pair programming right. Often, the only conversation that happens during pair programming is conversation about what was not visible on the screen: "Why did you do that? What made you think that was the right thing to do?" The only thing we need to talk about is what's not manifest there on the screen. The longer we can go without talking the better.

One of the things I love about pair programming is sometimes you just point to the screen, and the other guy says, "Oh," and does something differently. Just directing the focus around on that screen is often enough. I think that has a lot to do with the efficiency of a program text to explain and represent a complicated thought. In other words, a complicated thought has a representation on the screen as this syntactic element called a computer program. I love computer graphics, but every system I've seen to try to turn programming into pictures has lost that syntactic element. There's something about syntax that makes it very precise for reading. I love photography. A photograph will tell a story. But words tell a story even better. Words are more versatile. You can paint a verbal picture that's much richer than you can photograph.

So if you program in the XP style day in and day out—if you practice to the point where what you do is on the screen instead of in your mind—how would that change other things you do in your life? You are using faculties differently. It is changing the way you think.

Bill Venners: It sounds a bit like living in the present instead of worrying about the future.

Ward Cunningham: Yeah, there's a zen feeling to it. I actually think the XP style makes you better at predicting the future because you just get a lot more experience in seeing how things work. Most of our ability to predict is just based on some sort of internal modeling. If we write 10 programs a day instead of one program every 10 days, we just get that much more experience.

Bill Venners: If you don't spend that other time designing?

Ward Cunningham: Designing, or getting permission to design because somebody else wants to do the design, or whatever. Instead of whatever else we would otherwise do, we instead just do an awful lot of programming. So there's a lot of seeing what happens when you do something, and that makes you a great predictor. So despite the anti-design approach, it turns out we end up being great designers.

What you end up doing is this: in your head you think, "Oh! Oh! I know how this is going to come out!" But then you think, "Well, it will come out soon enough." You could discuss it, but it will come out soon enough. You see stuff coming, but you ask yourself, "How would I make things better by discussing it?" We're working together and you're programming away. I could say, "Wait! Wait! I know what's going to happen down here!" Well you knew what was going to happen down here. How does it help us get our job done for me to tell you what's going to happen down here? You could say, "Stop! I want to draw on the white board what we're going to do tomorrow, because I can see it coming." Well maybe I can see it coming too, but why make a commitment? It will come soon enough. So, we're certainly here and now, but I think we can become excellent predictors. It's just that we're careful not to depend upon prediction anymore than we have to.

Next Week

Come back Monday, January 19 for the final installment of this conversation with Ward Cunningham. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Resources

Bo Leuf and Ward Cunningham are the authors of The Wiki Way: Quick Collaboration on the Web, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020171499X/

Ward's Wiki:
http://c2.com/cgi-bin/wiki?WikiWikiWeb

Ward's Weblog:
http://www.artima.com/weblogs/index.jsp?blogger=ward

Portland Pattern Repository:
http://c2.com/ppr/

Information on CRC (Class-Responsibility-Collaboration) Cards:
http://c2.com/cgi/wiki?CrcCard

XProgramming.com - an Extreme Programming Resource:
http://www.xprogramming.com/

FAQ-O-Matic:
http://faqomatic.sourceforge.net/fom-serve/cache/1.html

PLoP, the Pattern Languages of Programming conference:
http://jerry.cs.uiuc.edu/~plop/

Talk back!

Have an opinion? Readers have already posted 19 comments about this article. Why not add yours?

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.