e-Talk Radio: Beck, Kent, 5 December 2000

get paired up with somebody for an entire project, and you can't stand them. That you change partners. That it's…

Kent: Yes, it's very dynamic. The scheduling algorithm is really, like a lot of things, XP takes a lot of its philosophical underpinnings from dynamic…complex systems theory. And so, we don't…There's not a schedule…pair scheduler, or a dance card that you fill out. It's more like, you come in the morning, and you haven't worked on your tasks for a day, so you're feeling a little nervous, and you say, "Well, who can help me on this GUI thing that I have to do?" And somebody volunteers. Or, if you have somebody particular in mind, because you know that they worked on it previously, you can ask somebody specific. So you do that for a couple of hours, you get a bunch of new test cases working. Then you integrate everything you've done and release it, so the complete release process, you run all the test cases, make sure you haven't broken anything. And then, you're available to be a partner for somebody else. So in the course of a day, you might pair with three, four, or five people.

Carol: Right. Interesting. One of the other things that's very strong in extreme programming is that you do the testing before you even write code. Can you explain a little bit about why you would do that? The advantages, and how that works?

Kent: I came out of the small talk world. In the small talk world, we…As far as testing goes, we just assumed we had this Zen-like oneness with our program, so if anything was wrong, we'd just know it in our hearts. Moving to doing commercial software was a little bit of a shock, so I…The best, most productive compiler writer I ever worked with wrote five lines of test code for every line of functional code he wrote. And I thought, this testing stuff is pretty good! This is a guy named Christopher Glaser. And so I started writing more tests, and I started telling my clients they should be writing tests. And I remembered a book that I'd read as a kid. I was a Silicon Valley brat, my dad was an engineer in Silicon Valley, and he'd bring home books, and I remembered this book that I read. I was maybe twelve years old or something. Here's how you program. You take the input tape, you know, for those of you who don't know what tapes are, it's like a really long floppy disc. You take this input tape, and then you type in the output tape that you expect from the input tape, and then you program until that's the output tape you actually get. And I thought, well, that's a stupid idea. Why would you write this test that you know fails? Right? You write some code, and then you write a test that might fail or it might not. But I'll just try it. And it was a magic transformation. It completely changed my relationship to my code. So what you do is, you say, "Well, I wish I had an object like this, and an object like that, and I'd send this message, and I'd pass this to the parameter, and I'd get this as the result…" And you just type it in as if it's already working. And then, lo and behold, it doesn't even compile, if you're in a language…a pessimistic language that doesn't even want to let you execute things if they don't compile. Like Java or