Ward Cunningham Quotes

Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.

I actually enjoy complexity that's empowering. If it challenges me, the complexity is very pleasant. But sometimes I must deal with complexity that's disempowering. The effort I invest to understand that complexity is tedious work. It doesn't add anything to my abilities.

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.

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.

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.

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.

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

Often, the program ends up amazing. You'll say, "This is beautifully architected." Well, where did that architecture come from? In this case, architecture means the systematic way we deal with diverse requirements. Architecture allows us, when we go to do work we need to do on the program, to find where things go. It is a system that was worked into the program by all the little decisions we made — little decisions that were right, and little decisions that were wrong and corrected. In a sense we get the architecture without really trying. All the decisions in the context of the other decisions simply gel into an architecture.

I like the notion of working the program, like an artist works a lump of clay. An artist wants to make a sculpture, but before she makes the sculpture, she just massages the clay. She starts towards making the sculpture, and sees what the clay wants to do. And the more she handles the clay, the more the clay tends to do what she wants. It becomes compliant to her will. A development team works on a piece of code over several months. Initially, they make a piece of code, and it's a little stiff. It's small, but it's still stiff. Then they move the code, and it gets a little easier to move.

Over and over, people try to design systems that make tomorrow's work easy. But when tomorrow comes it turns out they didn't quite understand tomorrow's work, and they actually made it harder.

You don't want to write a big comment that tells others how to make a change they might want to make, because you don't know what change they're going to want to make. Better to have the attitude that you can't help future programmers make their changes. All you can do is make it easy for them to understand what you were trying to do. And it will be easiest for them to understand what you were trying to do if you were very careful to not try to do too much.

Traditionally, the cost of change curve said that if we detect the need for a change early, it costs less to make the change than if we detect the need late. I tackled that curve by saying, let's almost intentionally make mistakes so we can practice correcting them. That practice will help reduce the cost of making changes late.
Our feeling was that the limiting factor on any change was not when it was done, but how much thinking was required.

We erased a problem by not trying to erase the problem, by saying, "This is in the nature of what we do." It's really weird that it could be that simple.

When you get in situations where you cannot afford to make a mistake, it's very hard to do the right thing. So if you're trying to do the right thing, the right thing might be to eliminate the cost of making a mistake rather than try to guess what's right.

It was a turning point in my programming career when I realized that I didn't have to win every argument. I'd be talking about code with someone, and I'd say, "I think the best way to do it is A." And they'd say, "I think the best way to do it is B. I'd say, "Well no, it's really A." And they'd say, "Well, we want to do B." It was a turning point for me when I could say, "Fine. Do B. It's not going to hurt us that much if I'm wrong. It's not going to hurt us that much if I'm right and you do B, because, we can correct mistakes. So lets find out if it's a mistake."