e-Talk Radio: Extreme Programming, 1 February 2001


But in systems that doesn't happen. We say, "Well, I kinda sorta think it's going to be like this." And we have these to-be-determined areas. Well, number one, how can you know if your requirement is right if you don't know what it's supposed to deliver? If you don't know how to test it? And that's one of the premises of Extreme Programming, is that you come up with your tests before you actually write a line of code. And if you can't test it, it's really not a requirement. So that's a bit of a problem. Now, it may sound like we spend most of our time testing, abandoning the solid requirements process, and really spend all our time coding in XP. So once you get the tests done, oh everybody just sits down and hacks. That's not the case at all. Actually, what happens is the analysis and design in XP lifecycle takes up 40% to 65% of the time. Coding is a mere 5%. And testing and support is actually 30% to 55%.


Caller: Yes.

Carol: Yes. Is that my guest?

Caller: No, sorry. Not your guest. Just an interested caller.

Carol: Oh, okay. I'll just finish this thought, and then I'll have my caller come on. So XP really focuses on doing a good job of analysis and design. Coding, once we have the requirements right. And then doing the testing and support and building the system iteratively. And caller, you're on the air. Hello? Okay, that's fine. We'll go to break and we'll be back with more of

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.