testing, and I'm for the idea of pair testing as well. I've done that to some extent in terms of reviewing bug reports. But really pair testing where you're both sitting down in front of one terminal. I'm looking forward to trying that. I hope it's an opportunity that I'll get.
Carol: And it's not a new idea. I was talking to a number of colleagues and they said, "This pair programming thing sounds kind of wacky." And I said, "Well, it's not a new idea." We used to do it, when we had punch cards, and if anybody can remember back to the times of submitting a batch job. And submitting a batch job and having to wait an entire day to find out if you put the comma or the period or something in the wrong place. And you'd actually submit it and you'd get it back and you'd say, "Oh, if I'd only seen that." So what we used to do is in the downtime, you'd program a lot of stuff, and right before you actually ran it through the compiler and submitted your batch job, you'd have somebody else look it over.
Caller: Yeah, it's really the idea of software inspection, which I'm a big proponent of. And the idea is that you inspect something as early in the process as you can. This is even moving it back further, and you're getting it inspected right as it's created, so it makes a whole lot of sense.
Carol: You're actually inspecting before you've written the code. By developing the tests early. And it's much more of an integrated process. I know that your question was that it seems a little bit disjointed. It's all an integrated process. You sit down with your users, you ask them what they need. You develop these things called "stories," which are similar to use cases in that they're small components. It's not a huge dissertation on what the application's going to do. We take a bite-sized chunk that is fairly well defined, and we program that. We develop the tests that we would need to prove whether or not it works. And I think that's really something that's proven itself, is "test-first programming." If you can't design the test, if you don't know how something is supposed to work, how can you program it?
Caller: Right. I still think that the user stories and how you configure the work space and how you deal with customers...for example, you can do pair programming without any of that...and you read that, they don't really say that XP works in all situations. That there are many situations where it's not practical. But certainly parts of it make a whole lot of sense. So in recognizing that you don't have to do all of it, it really would make it more valid in more situations.
Carol: And I think one of the problems is that people say it's got to be a Swiss Army knife. I don't know where we got that idea. Maybe from the infomercials late at night when they say, "Don't order yet, we'll include the Ginsu knives, and and and..." But there's nothing that's a Swiss Army knife. There is no Swiss Army knife of metrics, there is not Swiss Army knife of "this will work on every single thing." And I think that sometimes we're looking for an excuse not to change. We don't want to change and do something and follow something and then it doesn't work, and then people will say to you, "Told you so! Yeah,