Sponsored Link •
Ward Cunningham talks with Bill Venners about using the programming language, rather than the whiteboard, to design and communicate ideas.
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.
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.