Ward Cunningham Quotes

The blogosphere is a community that might produce a work. Whereas a wiki is a work that might produce a community. It’s all just people communicating.

A wiki is a work sustained by a community.

My hope is that wiki becomes a totem for a way of interacting with people. Tradition in the work world has been more top down, while wiki, standing for the Internet, is becoming a model for a new way of work. Largely driven by reduced communication costs, it changes what needs to be done and how it’s going to get done. I hope that the wiki nature, if not the wiki code, makes some contribution.

What I'm really doing is I'm trying to preserve the right for a programmer to think while he's typing. If you feel that it’s not going well, you can stop and say 'What did I get wrong? Let me correct it.

There is a programming smell here… which is kind of like the smell in your refrigerator, you know. There's a sign that there's something wrong, but you can't quite put your finger on it. But you know if you leave it there, its only going to get worse.

When a manager asks for hard data, that's usually just his way of saying no.

I don't claim to be a methodologist, but I act like one only because I do methodology to protect myself from crazy methodologists.

There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped.

You are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?" I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it.

Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.

So today, let's write a program simply. But let's also realize that tomorrow, we're going to make it more complex, because tomorrow it's going to do more. So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll preserve simplicity as the program grows.

There is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.

If you write a lot of programs, and you're used to squeezing them all the time, you find that it's easy to write a program that's simple. A lot of it is having a clear sense of what you want to say — writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn't matter.

What is simplicity? Simplicity is the shortest path to a solution.

The complexity that we despise is the complexity that leads to difficulty. It isn't the complexity that raises problems. There is a lot of complexity in the world. The world is complex. That complexity is beautiful. I love trying to understand how things work. But that's because there's something to be learned from mastering that complexity.