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.
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.
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.