C++. And then, so you get it to compile, and then you get it to run. And then you go to the next thing on the list. You say, "Well, here's another scenario that ought to work. If I have an object like this and this one's a little different this time, and I'd send it, then the answer should be thirteen instead of eleven…" And then, lo and behold, that one doesn't work, and then you go make both of them work together. And just that little twist of writing the test before you write the code makes all the difference. At the end of the day, you have all of these tests, so you're totally confident that your software works, to the limits of your knowledge. If you're ignorant, if there's something you don't know to do, the software won't do it. But everything, to the degree your tests reflect everything you know, the software demonstrably does all those things. And while you're typing those tests in, you're actually making a lot of analysis and design decisions. You're thinking, what is in scope? What things should I be able to calculate? What should the answers be? And, at a logical design level, how am I going to reflect that in the objects, in the interfaces that I have?
Carol: It's almost like doing outcome-based programming, where you've got the outcomes sitting there, and then writing the code after.
Kent: Right. Yeah. And the astonishing thing was, as an individual just how much difference that makes. And then the effects are compounded when you have a whole team that's working in that style. You tend to write much simpler code. You have much more cohesive, loosely coupled objects, because they're easier to test. All you have to be is lazy to be a good designer. Because you don't want to write complicated tests, so you figure out ways of making objects so that the tests are easy to write. You have all of these tests that come spinning off as a byproduct of the process. And those should run forever. You run those many times a day, for as long as the project lives, so that you make sure that you don't have regression.
Carol: Right.
Kent: And they provide a very nice conversation piece for the programmers to discuss. You know, you're sitting there with your pair, you say, "The answer should be eleven." Your partner says, "It should be minus eleven." Well, it's great to be able to talk about that at the moment when you have the test in front of you, instead of being down there in the middle of code or something.
Carol: And we'll be back to follow up with Kent Beck and more of extreme programming after these messages.
Welcome back to show. I've been interviewing Kent Beck on extreme programming. And I have about a million more questions to ask him. And about six more minutes to ask him them. So, we'll do an extreme programming approach to questions. What do you think?
Kent: Okay.
Carol: Okay, what's the difference between XP and light methodologies?
Kent: The difference between isn't how I'd ask it. I'd say…XP is an example of a number of different software processes that suggest that people are at the center of software development, and give as much attention to sociology and psychology as they do to technology.
Carol: That's an interesting way of putting it. Now, XP is not a heavy methodology like some of the ones that we've seen in the past. What I've seen is
About the author
Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.
