Ward Cunningham
|
|
|
Ward Cunningham
|
I really enjoyed interviewing Ward Cunningham for this column. As you'd expect, the inventor of Wiki, and co-progenitor of Extreme Programming, had plenty more to say than I could fit into the column. Here are some outtakes:
On knowing what's good enough:
"Business is always churning the logic to compete in the free market. That's what business does. It will always move faster than the programmers can keep up with. Most of business programming is about getting a wrong program to do the right thing by being even smarter. People resent these systems because that's what they have to do. The program is a boat anchor dragging down the pace of business, and it's almost set up so that it can't be anything but.
The real challenge is to break that cycle. To get the programming fast enough so that it's not a boat anchor. I see two ways to do that. First, make sure the programming has longevity, so we can keep modifying it and keep it correct, without becoming gigantic and brittle. And another, frankly, is to program less. There are lots of things we can program, but just because we can doesn't mean we should. The business sponsor who says, 'Wouldn't it be nice if the program also did X,' isn't reasoning through what the burden on even he will be when the program is insisting that you do X, and he doesn't want to do X any more, he wants to do Y.
There's a real tradeoff. Is this function worth writing? Extreme programmers are good -- maybe not great -- but good at making that tradeoff. They work as a team, doing small releases over and over. The business sponsors get a sense of what's possible, and what the cost is, and what the cost of change is. They practice accepting new releases every week.
One reason XP gets projects done quickly is that people say, this is good enough. Of course, good enough means good enough for the requirements. What's good enough today will be not good enough tomorrow. So the quality of the program, from the programmer's perspective, has to be excellent -- so that you can always do the next thing when that next thing becomes important."
On old habits:
"A lot of our habits are left over from a small-memory world. There was a time when you couldn't get the whole program in memory. So it became important to discard the names used in a program when the program is done. I take issue with the idea that you don't have to call things what they are. And I take issue with the notion that the program will get done. Any program that's being used isn't done. The notion that it'll be done, and we can forget about it, is the biggest lie that we've founded our practices on.
Now that we have large memory, we risk creating a massive and brittle web of small-thinking programs. Who are these systems built for? They're built for businesses, and yet we still don't have a good and rich representation of basics like money and time."
On correctness, testing, and knowledge representation:
"By correctness I mean: is is it error-free? Can I run it without crashing or throwing exceptions? But even if it runs and prints numbers, do those numbers mean anything? The type system doesn't help you there. The type-checker in the compiler is there watching out for itself, it's not watching out for us. There's no knowledge, really. If you get good at using types you find ways to use type names to try to hint at knowledge, but it's not really net present value, or cost-weighted rate of return. Whatever these things mean, that's knowledge.
A lot of the test-first approach is about getting some knowledge into our tests, so the tests embody that knowledge, and check that the program matches what we think is going on. You construct tests to make sure that the logically correct program also matches that knowledge."
On interpreting business information:
"A good business runs on continuous reintepretation of objective reality. Right now, it's hit or miss. People running big corporations don't have facts that make sense. One problem is that all our fact processing is based on numbers. If you need to interpret manufacturing productivity, you're all set. But if you need to interpret customer satisfaction, or the accumulation of expertise in your teams -- that's not numerical. So people blow away accumulated knowledge left and right, and they think they're playing hardball.
The business systems of the future will allow people to have competing interpretations of objective reality. They'll allow those interpretations to battle, and may the best win. In terms of equipping board members to do this kind of thing, IT, so far, hasn't held up its end of the bargain."
Former URL: http://weblog.infoworld.com/udell/2003/02/13.html#a605