Go Parallel
Interview With Ward Cunningham

The creator of the Wiki dishes on the Wiki, Wikipedia's policies, OO design, technical debt, CoffeeScript and Perl, how to survive as a veteran programmer, and doing the simplest thing that could possibly work.

By Andrew Binstock
May 15, 2012
URL : http://www.drdobbs.com/architecture-and-design/interview-with-ward-cunningham/240000393

Ward Cunningham is the winner of this year's Dr. Dobb's Excellence in Programming Award. The award, given out irregularly since 1995, recognizes particularly meritorious programmers and their contributions to software development. It includes a $1000 donation made by Dr. Dobb's to a charity of the winner's designation. This year, Cunningham chose the Wikimedia Foundation, the organization behind Wikipedia and related projects.

Cunningham's contributions are to software are numerous. He developed the first wiki as part of his efforts to create a repository of design patterns. First known as a "WikiWikiWeb," the wiki concept quickly spread as an easy way for programmers to share knowledge between themselves and with a community. Cunningham also wrote the Fit test framework, which enabled UATs and other tests to be encoded in HTML tables and run as such. It's the basis for the widely use FitNesse framework. Separately, Cunningham was the co-inventor (with Kent Beck) of CRC cards. Recently, he has been advancing the concept of technical debt. As part of his award, Cunningham sat for an interview with editor Andrew Binstock, which is excerpted here.

Technical Debt

DDJ: Let me start by asking you about a concept that has recently gained currency, namely, technical debt. As you explained it in a few videos and in some writings, this is a concept of debt being paid forward to future folks who will maintain the code you're writing today.

Cunningham: The thing I was questioning is the notion that some people write code and other people maintain it. That programming was housekeeping and the blank sheet of paper was the creative space. Keep in mind that I originally discussed this before we had the word "refactoring." Some people might have used that word, but even when I talked about it in an often-quoted paper, I think I called that consolidation, not refactoring. In other words, you figure out what it should have been, and you make it that. Whereas the prevailing wisdom at the time was, "If it's not broke, don't fix it." So the first time you got something working, you quit. That's not a way to make great code.

I was really devoted to finding great code, especially when objects were new. Objects gave us an extra dimension beyond functional decomposition. And the question was, "Are these the right objects or not?" And the answer was, "Time will tell." You know, you've got a job to do. You've got to make the objects be the right objects and get the functions in the right place, and all that stuff we call refactoring. I had to explain that to my management.

The notion that you grow a product is something that people would say, but then I had to say, "Here's how to think about that growth process." I needed a term that the financial executives would understand, and they understand money. So debt is a good metaphor.

Whether you call it debt or not, but quantifying the intellectual position that you are in at a particular time in the lifetime of a body of software, is useful. And if we can be paying attention to that, and it we could convert it into numeric form, and that numeric form could be converted into dollars, you know, that's all good.

CRC Cards

DDJ: One of the things that you were involved in in solving that problem of figuring out early on what your objects should be and how to involve them, was CRC cards, which I always thought were a useful device. But they never caught on. Do you have a sense as to why CRC cards didn't remain a part of design practice?

CRC cards show Class (top), Responsibilities (left), and Colloborators (right) (Courtesy of Cunningham & Cunningham)

Cunningham: The style early on, when objects were becoming important was that people would say, "The most important thing about objects is the hierarchy. And if you want to understand hierarchy, study the library and the Dewey decimal system, because librarians understand hierarchy, and they'll tell you how to get everything to fit into one hierarchy." I thought that was misguided. Because there's not going to be one hierarchy, or all of our filesystems would look the same. Everybody's got their files and folders set up differently. It isn't the hierarchy that matters, it's how you share responsibility, or distribute or divide responsibility between different objects, maybe in different hierarchies or maybe hierarchy doesn't matter. Different objects that are working together to get something done — that matters.

What I cared about was: Here's an object that's responsible for A, and here's another object and it's responsible for B, and when A and B need to get together, these objects are gonna do it somehow. That is important. Of course, what kind of turned out is that objects are used for just about every purpose except for building meaningful models of business problems.

I liked to imagine solutions to business problems with business people sitting on one side of the table and programmers sitting on the other side of the table, and these cards spread all over the table are the props that they can use to have a conversation. But the developers then thought that it was their job to go and make the business objects that work for this problem, and I was just saying, understand your users, understand what problems they have before you start making up those objects. And if you do make up those objects to solve your problems, expect them to understand them.

At one client, we had a menu system where, when the user clicked on a certain channel, a menu would pop up with things that the user could do. And I said, "Let's make the term that pops up in the menu be the method name that does the action in the program." And people looked at me and said, "That's crazy. They haven't decided what those menu items are going to be." And I said, "Every time they change the menu item, we'll rename the method." And you know what? They changed them a few times and then they settled on the names. And then we all spoke the same language.

So the things that are important, you have to have ubiquitous terms for. And when you can make those terms be the organization of your program, then you're somewhere. But that's not what we do, so we miss that opportunity. And that's what I think happened to CRC cards. CRC cards were all about doing that.

Doing the Simplest Thing That Could Possibly Work

DDJ: You once wrote, "We're told: Always put checks in, always look for exceptions, always handle the most general case, always give the best user advice, always print a meaningful error message, always this, always that. There are so many things in the background that you're supposed to do that there's no room left to think. I say forget all that and ask yourself, 'What's the simplest thing that could possibly work?'" But in many ways those voices that you suggest holding in abeyance keep us from writing smelly code that generates debt that has to be resolved later on. Where is the balance between those two things?

Cunningham: Actually, there's a path where you get to address them both at the right time. If I've got a month to work on a project, I have to ask, "What am I going to do the first week?" In fact, when I go in there on the first day of the first week, I have to ask, "What am I going to do on the first day?" I have to be making progress everyday. But if you think about too many things at once, you get into this kind of fearful state.

Sometimes you have to consciously ignore things that you know you're going to have to do. And those could be things that you just always have to do. And they might be things that people have told you you're going to have to do. That ability to focus is critical. To do the simplest thing you know.

Long ago, Kent Beck and I would be talking over coffee about what we might or might not do. And we would look at each other and say, "Well, let's go see if we can do it." And we would run downstairs to our office and sit side by side at a Smalltalk machine and just start coding in it. And sometimes it just delivered. Other times we'd sit there and minutes would go by. More minutes would go by. We'd think, "Why is this hard?" "What are we missing?" And we would feel that there was something wrong in the system, but we had no idea where the next step was. And that's when I realized that we had to free ourselves from whatever we thought we were supposed to do. And I just asked the question, "What is the simplest thing that could possibly work?" And you drop whatever you thought the solution was to what you were trying to do, and you say, "Well, if you wanted to make it really simple, you would just return the right answer. Or just look it up in a table." Or something that would be embarrassing to have your colleagues look at it and see what you've done. But you know, you could say, "We could do that. Let's just do it. We've been wasting 45 minutes on this problem, and we could do that simple thing in one minute." And we'd see it work. And then as soon as we'd see it work, we'd think of three more things we could do, maybe other ways to solve that problem or three other problems that are related that we didn't even realize we had, but it was like a door swinging open. And on the other side of that door was just fun things to work with. And the fact that we would sit there banging our head against this door for 45 minutes and not reach down and turn the handle because we thought we would be embarrassed to have cheated that way.

DDJ: But eventually...

Cunningham: Of course, at the end of the day you have to say, "Have I made code that I can live with?"

How Many Design Patterns Are Enough?

DDJ: Patterns were the prime motivation in your original design of the wiki. It seems that one level there are far too many patterns. I think that most developers today who are familiar with the Gang of Four (GoF) patterns are familiar with a subset. I'm not sure that, for example, that everybody walks around knowing how to implement the interpreter pattern, for example. On the other hand, I see you developing a vast collection of patterns. To what extent should patterns be a part of a developer's life, and in answering that question, to what extent should the full set of 23 GoF patterns be an integral part of developers' lives?

Cunningham: Good question. You know, I said nice things about the Heads First Design Patterns book. And one thing that they did is they said, "These are the 12 patterns that everybody uses, and if you're working on a job, there are these words, and you'd better learn them. And we're going to make learning them easy." That was a recognition of the success of the original Design Patterns book. So the fact is, anymore, you don't even have to study that stuff. If you're just an everyday programmer, those words get kicked around so much that you'll learn them by association.

The impact of patterns hasn't been so much in the written form, but just the fact that people use the words effectively and fairly precisely. Maybe proxy is used too many ways. But the basic patterns have done their job. And then of course, you should ask, "What was that job?" And this is the thing that surprised me. The job was really to take C++, which was a fairly static language, and show people how to write dynamic programs in a static language. That's what most of the patterns in that book were about. And in the process, patterns extended the life of C++ by a decade, which is not what I thought would happen. What I thought would happen is people, when they learned these patterns, would look at them and say, "Wow, these patterns are hard in C++ and they're easy in Smalltalk. So if I want to think in terms of these patterns, I might as well use a language where they're easily expressed." And extend the life of Smalltalk by a decade. But the opposite happened.

I think the reason why the wiki is popular is because it's the first medium that disregarded that hierarchy. And it allowed people to contribute based on their own understanding of what was valuable.

The Wiki

DDJ: Well let's talk about one aspect of your work where I think you will admit the results of your work greatly exceeded your expectations: the wiki. What made it so successful?

Cunningham: I think that the thing I did right there was respect the people who would come that I didn't even know, who had no right to deserve my respect because I know nothing about them. But I would say, "Come on in and I'll trust you to contribute in good faith and to make your words a gift to this community." And we did. It was magical. I tell you I felt so good everyday. For the first couple of years I was on that thing for a few hours a day. This is the original wiki, which is about the programming, and I loved it. I will say that everyday that I spent hours on that wiki, I would say to myself, "I've got to stop doing this. I've got to focus on my business. I have work to do." Thank goodness I didn't bother to do that work and fiddled with wiki instead!

DDJ: It's astonishing that wikis haven't been corrupted. They haven't been turned into garbage dumps by people who like spending time doing those kind of things. It sort of reaffirms a little of one's faith in humanity.

Cunningham: There was the invention of wiki spam, and that made it a little less fun. What's going on there is you create something of value, and once it becomes valued, people give it attention. And the weakness of wiki is that it says, "Anybody gets the same access to that attention." So the more successful you are, the harder it is to be a wiki.

But let me switch back to why I think it worked. What we really did was say was the command and control hierarchical communications that we had to use in organizations wasn't necessary anymore. In fact, it was an impediment. It wasn't that it couldn't work. It was that it was unnecessary. And I think the reason why the wiki is popular is because it's the first medium that disregarded that hierarchy. And it allowed people to contribute based on their own understanding of what was valuable. And that has grown up with an understanding in organizational theory that you have to work that way. In fact, organizations are flattening left and right, and they might even say they're becoming more wiki.

DDJ: In terms of Wikipedia, would you be an deletionist or an inclusionist?

Cunningham: Oh boy, I don't know if I have an opinion. Because those terms actually emerged on my wiki and I'm not sure I had an opinion there. But we were counting the number of pages and it was kind of a special day when we passed 20,000 pages. And then someone said, "Gee, maybe that's about the right size. We don't want to be any bigger than 20,000 pages." And I thought that was a very interesting idea. And then some people said, "Well, it's now 20,100. Let's beat that 20,100 back to 20,000." And so I saw it as an experiment. There were plenty of tiny little pages that nobody ever read. I think I even made some tools to help people find them and they went and deleted them. And other people felt that anything that's written is worth keeping, and they were insulted by that. So then it became aggressive, and judgmental —and I'm having a little trouble remembering how it all worked. But I do think that we get a lot of value out of focusing our attention. But I think the whole notion of, to think about Wikipedia, the whole notion of encyclopedic sort of says everything, doesn't it? It means broad.

DDJ: Even though I tend toward the inclusionist side, sometimes when I look up somebody and I go to a disambiguation page that contains 45 entries I wonder to myself whether we need to know about a non-medal swimmer on the 1948 Olympics team.

Cunningham: I think that Wikipedia has been handling that fairly well. We could talk to people who are a little closer to the day-to-day Wikipedia and they could probably even correct me on this, but I think the more important notion is notable. The community has to agree upon what the criterion of notability is, and that's only because, there are forms of abuse that arise from non-notable people feigning notability. And that's the fight. And once you start fighting that fight, you find all kinds of stuff that doesn't pass muster that wasn't hurting anybody. And you say, well, in the sense of fairness, I've got to delete it too. And that's a tough thing.

DDJ: What about a separate wiki for non-notables?

Cunningham: That would be a good thing. I do know there's a deletipedia or something like that, with everything that's ever been deleted from Wikipedia. So if you want to go see what's been removed, there you go. My solution is, it's easy enough to set up a site, so let's let everyone have their own wiki, and let the notables surface through kind of an evolutionary process.

DDJ: One of the big problems with wikis today is their complete non-portability. Do you have any thoughts about having some kind of standard markup or markdown format across wikis, or that they could all convert to, so that people could move wiki entries from one wiki to another? Do you have any thoughts on that?

Cunningham: Well, I do consider that a problem. I will point out that the wiki markup was completely portable until the second guy implemented a wiki. [Laughter.] But there was a time when wiki was young, and I was surprised at how often and how varied it was when cloned. Then I discovered 25 different ways to specify boldface. Do we need 25? Probably not. On the other hand, HTML had a completely adequate way to specify boldface and I chose not to use it. Actually, it had two ways, and I chose not to use either one of them. So I guess I'm not devoid of blame. As long as people have talked about the Tower of Babel, they've been wondering why we can't have just one language.

DDJ: I could extend this conversation to the back end, to the database entries for a wiki. It certainly seems like there should be some standard format that you could convert back and forth from.

Cunningham: I think there is a standardization project that got started, and then they approached me and I said, "You know, we're never going to get a standard, but we might come up with an interchange format. A little bit of everything, and good enough that you can communicate even if it isn't faithful to everything. And suggested the word "creole," which is kind of mixed language, you know, the native language and the enslaving oppressor language getting mixed together. So a couple years of effort, maybe more, went into defining that interchange format, including the strict and generous parsers of it. And it's been adopted in a number of places. It's just one more markup. So the only thing I can conclude is that as nice as having a universal or portable markup would be, it's not nice enough to cause people to give up what they're working on when they work on their wiki. I accept that as the state of nature and don't worry about it too much anymore.

DDJ: So is there, somewhere floating around in the universe, that interchange format for wikis?

Cunningham: Well, we ask that wiki implementers be able to read Creole and convert it to their format, and maybe export Creole. But if it ends up looking a lot like a mediawiki format, and maybe even a broken one at that, so if you didn't like mediawiki and you like something else, you want to do that. It had a fair shot at success and it didn't succeed. I will say that I'm trying again, and this time the hot new format that all the web kids do is JSON. So I'm saying, "Well, you know, at the higher levels, at kind of the page layout level, I'm happy with JSON. I'll use JSON. It's kind of a backend representation. And I'll have back ends talk to back ends passing JSON around. I think that that will be interesting. It's not going to replace mediawiki format, but for a new class of data wikis, I think it's just fine.

In the blogosphere, everybody gets their own blog site however they want to do it, and we all read each other's blogs. But that doesn't have the sharing characteristics of a wiki.

DDJ: So, what are you working on?

Cunningham: I'm wondering, where do all the wikis go to die? Or can they be immortal? In the document-preservation world, they say the only way to make something last forever is to let it duplicate without bounds. So I'm very interested in massive duplication of content. Of course, whenever you say prolific duplication, you've got to say, what gets duplicated? And it's kind of like gossip. And it puts out content out in kind of a Darwinian space, where the people who are paying to keep the disc spinning get to keep as much content streaming as they want. And the wiki aspect of this, of course this is exactly how the blogosphere works, right. In the blogosphere, everybody gets their own blog site however they want to do it, and we all read each other's blogs. But that doesn't have the sharing characteristics of a wiki.

And what I'm asking is, "What can I do to make something that has the storage and ownership sort of feel of a blogosphere but has the sharing capacity and the forming of consensus, as opposed to going off into our corners and talking to ourselves?" It's that consensus that you find in a wiki, and I believe I can do that by basically adhering to the formula that the Creative Commons gave us years ago, which is attribution, share alike. So I'll put my stuff out there and you're free to take it and make great stuff out of it, but just give me attribution, and when you're done, just share it the same way I am. And that's a formula.

Now if I back that up with software that makes that attribution automatic and makes that sharing, that creativity, let's call it refactoring. Let's say you write an article and maybe you write an article about me, and then I grab it and I say, that's not quite right, and I rearrange it because this week I think this is more important. And then my buddies look at it and say Ward is so vain, that's not important, these are the only three things he's ever done, and rewrite that article again. And it could bounce around a long time. And I wouldn't have much say about what they write, but I would be proud that they're writing about me. My notability will be measured by the number of people who bother to waste this space on me. So I call that the federated wiki, and the federation is the protocols that let us share effortlessly. So you have to kind of be OK with sharing, and kind of stamp that creative commons license on the page.

Now I call my project the smallest federated wiki, and that's just my excuse for really focusing on federation to the exclusion of a lot of other things. If I call it a wiki and I don't have any way to resolve conflicts, well, that's because I don't anticipate a lot of conflicts. If somebody else wants to put some conflict avoidance stuff or resolution into my wiki, that's fine. And I'll no longer be the smallest one. I have kind of a reputation for making systems that barely work but are always interesting.

DDJ: The smallest thing that could work, right?

Cunningham: Yes.

Current Programming Environment

DDJ: Tell me a little about your programming environment. What tools do you use for your day-to-day work and what languages are you programming in?

Cunningham: You know, I try not to get bound too much to anything in particular.

DDJ: I presume you must be using JavaScript if you're doing wikis and using JSON.

Cunningham: I'll tell you right now what I'm using and I'm enjoying is I write CoffeeScript, and TextMate, although I'm trying to learn Sublime Text 2, which I guess is the hot new editor. So, I switch back and forth between both of those. And it's been really nice. And of course, I love it because with one keystroke I can see the results of what I've written. I can select a paragraph and say, "run just this part." So it has this feel, that it's not very far from the engine. Of course, what engine is that? Well, there's node.js running right behind that, so I'm pounding things into node.js without hardly thinking about it.

I looked at it and I said, 'Who would have thought of making a language like that?' That's when I realized that open source was here to stay. There is no commercial endeavor that ever would have invented Perl.

In CoffeeScript, it feels very nice for me for doing the kind of things I'm doing now, which is programming event-driven stuff that's deeply nested, and it does that well. I will admit that I was a Smalltalk zealot, and I believed that Smalltalk could be the only language, and I knew about a dozen reasons why, and one of them was that once everybody programmed in Smalltalk, we would all communicate with objects. But that didn't happen. And the day that I gave up on that vision, I said, "You know what, we're all going to communicate with text files. We're all going to go ripping through these text files plundering them for whatever information we can infer from it."

That's when I picked up Perl. And it shocked me, just how well it worked for finding and plundering files because it had those reg exes built in and stuff like that. And it was so fast. It was fast to compile, it was fast to develop, it was fast to run. I could not believe it was so fast. And I know people like to complain about it, but I also thought it showed a tremendous amount of insight. It was insight, and I looked at it and I said, "Who would have thought of making a language like that?" That's when I realized that open source was here to stay. There is no commercial endeavor that ever would have invented Perl.

But Perl was my escape from object-oriented programming, and I still use it today. Probably a day doesn't go by that I don't just pick up Perl right at the command line just because idiomatically I can write commands. I know there's a command in UNIX but rather than go the command page and try to remember the options, I just write it from scratch in Perl. You know, I go on and finish the line. I know Perl well enough that I can do that. I think if you write big programs you know stuff that I never bothered to learn about Perl.

And of course Ruby has Perl as its father and Smalltalk as its mother, and so Ruby feels pretty good to me too. So those are the ones I like the most. And I've got a Macbook Air here, which is a pretty nice computer, especially if you commute by bicycle, it's not very heavy. I haven't bothered to update to Lion yet.

Learning As a Veteran Programmer

Cunningham: I'd say that computing is fabulous right now. It's a little complicated, but it's fabulous. And when I step back and look at my whole career, there was this time when we talked about how in the future there will be component libraries that have perfected solutions for everything that you would want to do.

DDJ: And you've had a long career to judge this.

That's the other thing: to be an old guy who's still a programmer. A lot of people think that you can't be old and be good, and that's not true. You just have to be willing to let go of the strengths that you had a year ago and get some new strengths this year. Because it does change fast, and if you're not willing to do that, then you're not really able to be a programmer.

DDJ: Well, it's not only strengths. You have to be willing to let go, just like you did with Smalltalk, of your affections for certain technologies. If you stick to Smalltalk and don't look at CoffeeScript and node.js, you become much less effective as a programmer.

Cunningham: Absolutely! And part of that is to say that there are some patterns that you've learned to put Smalltalk to work, or there are patterns that you've learned to make Perl programs work well. And when you go into the new world, some of those patterns don't come with you, and you can be really annoyed at that. You can feel insulted that you bothered to learn that and it's not good anymore. You just have to put that behind you and say, "What am I going to learn today?" And it's easier to learn good stuff, because there's great code out there. There's a lot of junky code. But there's great code, and if you find developers who really do their craft well, and read their code, that's the best way to learn a new language.

DDJ: When I look at good code, I frequently think, "I never ever thought of doing that that way." The joy of those small revelations is a wonderfully instructive thing.

Cunningham: Let me close with an example that is close to me today. I was looking to make things move on the screen and I fell upon this d3.js library. It's a nice library with a lot of examples of it doing impressive things. And then the code for those examples is 20, 30, 40 lines. And then I read the introductory material, and it says, here's our philosophy, and I agree with their philosophy. I like the picture and I like the look of the code. It's only 40 lines, but every line carried some careful thought. There was a learning curve there that surprised me because the programs looked short. The most rewarding work I've done this year is digging through that code and understanding what it does and understanding what it didn't do, and how to approach the problem.

Anybody who's willing and wants to have pictures on the screen that move, I would encourage them to do the same thing. But do it with an open mind, because you're following the footsteps of a very skillful developer.

DDJ: Thank you.

Copyright © 2012 UBM Techweb