Bill Venners: Let's look in particular at the question of how far to look ahead. I'll give you a metaphor. Oddly enough, when I first encountered test-driven development, it reminded me of Grandma Moses. When I was a kid, I took oil painting classes from a lady named Flora Yentes. And she taught me to first sketch the image in charcoal, then paint over that with yellow ochre. After that dried, I could rub the charcoal away and have an outline of the painting in yellow ochre paint. Then she had me paint a wash: broad brush strokes with thin paint that fleshed out the general colors and shapes. Finally, once the wash was dry, I painted in the details.
Grandma Moses didn't paint that way. She said, "I paint from the top down. First the sky, then the mountains, then the hills, then the houses, then the cattle, and then the people." She didn't sketch out the big picture then fill in the details. She started at one corner and incrementally painted details across the canvas. Test-driven development reminds me of Grandma Moses's style of painting. Instead of first fleshing out the big picture with some up-front design, I just look at the first piece of functionality. I write a test and implement the code. Then I look at the next piece of functionality, write a test, implement the code, refactor. I repeat that process all the way across the canvas.
I have used a disciplined test-driven approach on several projects, and it has worked well. But I still like to do up-front, big-picture thinking before coding. So in practice, to what extreme should we follow XP's advice to not look ahead?
Ward Cunningham: Here's what really converted Ron Jeffries: Ron knew how much he knew, because he had written every kind of program. He is a dogmatic zealot for XP, because he discovered he could actually produce better code by consciously not thinking about tomorrow. Not that he was going to forget anything he knows. Tomorrow will come soon enough. And tomorrow he'll say, "Now it is time to do this." He'll say, " I'm going to take everything I've learned in the project so far, and everything I knew before this project, and I'm going to make a decision today, because today is finally here."
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.
That doesn't mean that you don't think. You'll find that you have a beautiful opportunity to think tomorrow, because everything is laid out. Tomorrow when you get to that point, where you really do need to use this experience that you have, you'll find that the particulars are right there in front of you. The codebase is ready to take what you're about to write. If a change is required anywhere, you have permission to make it. And at the end of the day you'll see the fruits of applying that knowledge.
The program will be much more receiving of your wisdom tomorrow than it is today, when you would need to tell the story without the aid of a computer. In other words, when I go to the whiteboard and say, "I think this is what we'll need, and this will be enough," I actually have less support in taking my experience and getting it into a design than if I just stay with the project and program it day in and day out. The programming language is a better language than the whiteboard for getting every valuable bit of my experience into a design.
Bill Venners: The programming language?
Ward Cunningham: Yeah, the programming language. Or if we invent a language or a configuration file or the sequence of buttons—whatever we make.
Bill Venners: The artifact.
Ward Cunningham: Right. 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. They'll just say, "Every time I try to do this, it's like going down a rat hole. I could put it here, but I have to change this thing. To change that thing I have to change this other thing. To change this other thing..." Or they try it and it simply blows up. It's just too hard to change. The program is very brittle. And in that environment they think, "God, I never want to do that again. I want get my ideas out. I'll just write my ideas on paper and I'll let somebody else do that junky work." But it's less effective. If you're really sharp and you have lots of experience, you can bring that experience to bear more easily by just agreeing to never let the program get that brittle.