Bill Venners: In Extreme Programming Explained, Kent Beck writes, "Collective ownership increases your feeling of personal power on a project. You are never stuck with someone else's stupidity. You see something in the way, you get it out of the way." What happens when different people's ideas of what's stupid clash? Isn't stupidity a subjective judgment?
Ward Cunningham: Yeah, I wouldn't have said it that way. 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 let's find out if it's a mistake."
We shouldn't make ourselves so much fortune tellers that we have to predict the future. Better to set up the circumstances so you can try B and see what happens. Now, it turns out that often the difference is inconsequential. Whoever programs it has the freedom to program it the way they chose, and it is just fine. Of course sometimes it does turn out to be consequential. We're doing something else and we look at it and say, "You know, this isn't going to fit in there because B doesn't really let it fit in." And this problem might have been what I was thinking about when I was promoting A, or it might not. It might be that the developer squeezes it in within the context of B. But you sometimes get these bugs or difficult enhancements. And then the developer says, "You know, I'm sick of working on this code." I say, "Hey, I'll take that bug." And they say, "Would you?" I say, "Sure, I'll take the bug. You did B. I'll work on B." So I can go in and work on it, and I'll try to use as much of B as is worth using. But with taking on the responsibility, I get the opportunity to make it do what it needs to do.
Bill Venners: You mean go back to A.
Ward Cunningham: If that's what's required.
Bill Venners: Or perhaps go to C.
Ward Cunningham: Usually it turns out to be C. It's a learning experience for both of us. If we decide without the experience, neither of us really learns. Ward won, and somebody else didn't. Or vice versa. It's too much of a battle. Why not say, "Well, let's just code it up and see what happens. If it doesn't work, we'll change it."
I can't tell you how much time is spent worrying about decisions that don't matter. To just be able to make a decision and see what happens is tremendously empowering, but that means you have to set up the situation such that when something does go wrong, you can fix it. When something does go wrong, it doesn't cost you or your customer an exorbitant amount. It isn't ridiculously expensive. 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.
For example, in one project we eliminated the cost of a mistake with frequent releases. And we did it by building a fairly elaborate mechanism for database schema evolution. We'd release weekly and we'd do a schema change every week. We could make different schema changes for different customers in different orders, and have it all come together and be right in the end. And because we did it every week, after about six or eight weeks, we believed we could do it. We were never afraid to do it. Most people say, "Whatever you want to do, don't do schema evolution unless you really have to." And at the end of the project they say, "Oh my god, we really have to." So without ever doing it before, they say, "As long as we're going to do it, let's do all of it." They make a gigantic project, something they have no practice in. And what do you know? They get it wrong. By contrast, we do it every week. Do a little bit every week. We get really good at it. We're never afraid of it. It's never a problem.
So 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. It's really more the approach of asking, "What do you want to be good at?" If you want to be good at it, find a way that you get to practice every day. If you practice every day there's no way you can help but be good. So, pick what you want to be good at. Well, you ought to be good at what you're afraid of. Then you'll stop being afraid of it.