e-Talk Radio: Extreme Programming, 1 February 2001

TEXT TRANSCRIPT: 1 February 2001
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus e-Talk! with Carol Dekkers, brought to you by StickyMinds.com, the online resource for building better software. This program will focus on the latest in the field of technology. All comments, views, and opinions are those of the host, guests, and callers. Now let's join your host, Carol Dekkers.

Carol: Good morning, and welcome to Quality Plus e-Talk! with Carol Dekkers. This week, we're just waiting for our guests to phone in. We have Ward Cunningham and Kent Beck, who are two of the three "extremos" from Extreme Programming. Just to tell you a little bit about Extreme Programming, um, Extreme Programming, the two people who are going to be our guests this week have had years and years of experience coming up with the Extreme Programming method. It dates way back to 1989 when they first did some presentations at the Object-Oriented conferences. And we'll just wait a couple minutes for them to phone in and I'll tell you a little bit about me and what I do.

I run a company that is based in Tampa, Florida. We specialize in helping companies, in working with companies to build better software. To do that, you use measurement, software measurement, through targeted training and consulting services and managing by fact. A lot of people may have heard of managing by fact, but if you've got a process improvement initiative under way and you want to know if you're improving, one of the first things you need to do is measure where you are today. Now, I have a special offer for anyone who is going to be in the San Diego area. I and a number of my colleagues will be at the Applications of Software Measurement Conference, which is run by SQE, or Software Quality Engineering, and they will be in San Diego. We will be there prior to the conference, and we are booking free consulting opportunities. If you're interested and you'd like to meet with us and talk about software measurement, what it might be able to do for you, where you need to get started, please send an email to me at [email protected], or go onto our Web site and from there, you can do the same type of linking. So, it's www.qualityplustech.com.

I'd like to welcome you as a part of our listening audience. This is our number five in a series of thirteen shows, which is also brought to you by our sponsor, StickyMinds.com, which is the online resource for building better software.

If you're listening through StickyMinds or listening through our Web site, I'd like to say "welcome" and I'm hoping that we're going to have a wonderful show today.

Let me get started by introducing our guests before they come on the show, as we're waiting for them to call in. Kent Back was my final series guest last season, on December 5. He's a programmer, he's been one since the middle of what he calls his mis-spent youth in Silicon Valley. His father was a programmer before him, and several of his children are showing what he considers disturbing tendencies along the same lines. He's best remembered for pioneering patterns for software development, the rediscovery of "test-first" programming, the J-Unit testing framework, and most recently, ... programming. In his spare time, he builds small, temporary structures on the 20 acres of his south Oregon ranch he shares with his wife Cindy, five children, two dogs and a variable number of waterfowl. One of the most interesting things about Kent Beck is that he has been around what seems to be forever, but I know he's not that old. And when you pull up his name on the Internet, you will find Kent Back's name everywhere, along with the other two "extremos," which are kind of like the three tenors of the opera world. The three "extremos" are really Ron Jeffries, Ward Cunningham, and Kent Beck, who have been involved with object-oriented programming and Extreme Programming for a very long time.

Kent wrote a book called "Extreme Programming Explained: Embrace Change". And that came out last year. And it has been a very, very insightful and actually a bible for many people who are looking at changing the way they develop software, changing some of the things that they know don't work, the traditional ways of building software. And Kent put those in his book, Extreme Programming Explained: Embrace Change, and we'll back to talk with Kent Beck after these short messages.

And we're back with Quality Plus e-Talk! I haven't yet heard from Kent Beck and Ward Cunningham. I'm not sure what's going on on the Oregon coast, but we're going to wait for them to phone in. Meanwhile, for anyone who's listening that doesn't know a lot about Extreme Programming, let me just bring you a little bit up to speed.

Extreme Programming, to a lot of people, they might look at that as being something similar to bungee jumping, or they have visions of people with laptops jumping off with bungee cords, or everybody's got piercings in the office, or something like that. But really, that's not the case in extreme programming at all. Well, a lot of people might say, you know, "extreme," that means taking risks. Extreme anything, if you take a look at extreme sports, the EXPN games, or the X-games or anything like that, it really means going to the edge, and really taking life-threatening risks. And XP couldn't be further from the truth.

XP really takes and minimizes risk by focusing on the things that work well and leveraging that. Let me give you a little bit of setting the scene for XP. Kent Beck in his Extreme Programming Explained book said risk is the basic problem, and I'll quote him: "Software development fails to deliver and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software." And that kind of sets the stage for what extreme programming takes a look at. What kind of things are plaguing us? Well, we've got things like false features, we've got cancellations, we've got changes in business, we've got defect-prone software that's delivered, we've got in this Internet age especially, situations where we have customers who can kind of tell you what they need in their software, especially if it's Web-based software. But they can't tell you really what they need sometimes until after they've seen what they don't need. And we used to call that prototyping in software development. Now we've got the challenge of really kind of Internet seed development. It was explained to me in this type of manner, that typically what we do on large projects, is we will plan, we will plan kind of like AAA, the automobile association, will do TripTiks. If you want to go from where I live in Tampa to Jacksonville, for example, TripTiks will give you every stopping point, every light change, basically, that you go on I-75. And it's all planned out to the nth degree, and it tells you exactly how much time it should take you to drive between Tampa and Jacksonville.

Well, what happens when the very first time you get in your car and you've got it all planned out, that you're going to be in Jacksonville at suppertime? You get in the car, you round the corner, and there's an accident, or there are road delays, or anything like that. Suddenly, that solid plan goes out the window. Let's apply that to Internet-type development. Today, in today's marketplace, the marketing managers are going to say something like, "I need to be able to have this, this, and this functionality today, immediately, right now. You have three months to deliver it." That's your challenge. So you start programming, and using the traditional way, what you would do is you would lay out the requirements. We would have a prolonged requirements-gathering process, and people would say, "Well, I kind of want that. No, I don't want that." They're not totally sure. And once you've finally got the requirements solid, and you start going into the analysis and design, guess what? Things start changing at Internet speed. So we've got to have a way to respond to these changes, to be able to deliver things incrementally so that you actually will have at least the structure or shell of a system being incrementally developed and delivered.

Now, for any of you who are listening who have more experience than I have in extreme programming, I've done a lot of research on it, I'm doing a presentation at the Applications of Software Measurement Conference. My specialty is the measurement area. It's not extreme programming. I've been exposed to it, I know a lot about it from a theoretical point of view. So if you're listening and you have Extreme Programming experience, from an actual point of view, I invite you to phone in toll-free at 866-277-5369. I know that there's even ISO standards, even though extreme programming is fairly new, ISO standards are starting to take a look at applying standards for XP. So if you've got views on that, why don't you phone in and share your thoughts.

And if we don't have Kent Beck and Ward Cunningham phoning in today, there may be a massive storm off the west coast of Oregon, or something may have come up that prevented them from phoning in. We'll try to get them later in the series to readjust their schedules so they can make it. Because both had confirmed that they were going to be on this show. So I'll give you the toll-free number one more time. It's 866-277-5369, and that's anywhere, it's toll free. So I'm just going to walk you through a little bit about who these three extremos are, what's the basis of Extreme Programming, and then talk about some of the things that work in measuring, and some of the things that don't work in measuring. Now, the three extremos are Ward Cunningham, who was really the Inventor, they call him. Kent Beck they call the Articulator, and Ron Jeffries, who actually runs the extreme programming site on the Internet, is called the Realizer. Now they've all got a lot of books, a lot of articles, a lot of things that are available. And one of the things I'll tell you about extreme programming that you may be interested in, and I'll give you a caution with it as well, is something called e-group. If you've never been exposed to an e-group, an e-group is an electronic group that meets kind of ad hoc, and they send email messages. The warning I'll give you is if you get involved with the Extreme Programming e-group, make sure that you do not ask for emails, because you will get 60 to 80 to 100 email messages per day from postings and threads. And these things will come on Saturdays and Sundays. I should have known something was strange when I signed up for the e-group back in December, early December, and the first message that was posted that came into my email box was one from somebody that I thought was very strange. I didn't think it even fit in with the whole context of the e-group on Extreme Programming. And what it was was a posting by somebody who said, "How do I handle email on vacation?" I thought that's odd--that doesn't seem like an Extreme Programming issue. But what they meant was, how do I handle the number of postings that will be in my mailbox when I get back from vacation and try and be able to go through this? Because if you're gone for two weeks, I can guarantee you, you probably have 400 messages. To get involved in the e-group, you would go to groups.yahoo.com (it used to be e-groups.com) and you would select "extreme programming". You can use that in the search at the very top, you'll register, it's a free registration, and you can get involved and see the people, the interaction, and the changes that go on and the postings and the concerns of e-programmers everywhere.

Let me tell you a little bit about extreme programming, and we'll walk through that. And then we'll talk about the metrics that we can use, or maybe not use, especially in Extreme Programming.

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software. That's Kent Beck speaking. Lightweight. What does that mean? Well, it's certainly not the old methodology-prone method of taking a look at things. And the fuller values are really communication. One thing that XP, or extreme programming, does is it puts at the heart of system development, the customer. The user. The people who are actually going to be working with the system, living, breathing, eating with it over the next several years. And it really forces the users to be part of the process, through the planning games, through stories. No longer can you have a user say, "I don't have time for that meeting." Users are actually in the same room as the programming team. Users work along with and build the requirements on an iterative basis. You can't escape. And if you don't like your users, you'll learn to like them. If your users don't like you, they'll learn to like you. Because communication's really the fundamental piece of Extreme Programming.

One of the other values is simplicity. And that comes through in refactoring, which is one of the major concepts. Taking a look at small, bite-sized pieces. Now, extreme programming is not for everyone. It is not for the huge, monolithic Department of Defense projects. It is really intended for programming teams of about three to ten people where your requirements are not solid. You're not stuck in a traditional environment. You're really a new type of company, where your system developments can work within some new ideas.

Feedback is also one of the values of XP, and courage. And that's a very interesting thing, because one of the things I've noticed about the XP e-group is that everybody seems to have a sense of humor. And when Kent Beck says that it's a new, fun way of programming, I really believe that. I think that it really brings the fun back into doing some of the programming and some of the development.

Who gets involved in XP? Well, you can't escape. You really have a unified group of programmers working with the managers, working with the customers. And that's an essential part of XP, and getting involved in it.

When we take a look at what are some of the things that happen in an XP environment, well, there's pair programming. What is pair programming? Well that's something where you can no longer sit down and program on your own. You always do it in pairs. Now think about that. You've always got somebody looking over your shoulder, so if you type something in wrong, or you take a look at something wrong, or you get stuck, you have a second pair of eyes that's sitting right beside you. One of the things Kent Beck said on our December 5 show--he said you really work together. When you work as a pair programming, you work together, and he says that what happens is that you're looking over somebody's shoulder, kind of like backseat driving. So as you're looking over this person's shoulder, and you're saying, "Okay, I don't think it should be done that way. No, I wouldn't do it that way. I think I should program it another way." Finally, he said, you've got this keyboard on a long, long cord sitting in your lap, and you finally get sick of this person after about fifteen minutes of saying, "I'd do it this way. I'd do it this way." You hand the keyboard over to them, and it's their turn to front seat drive. And you become the backseat driver. It works very, very well. And you don't Extreme Program, you don't pair program, with the same person throughout the entire project.

Now, one of the other things that Extreme Programming focuses on is "test first" before you actually write any bit of code. This is one of the major problems that we have in traditional development. People can't really say what their requirements are, and for a long time, I really thought that that is similar to, in building construction, that we pour a foundation before we have a floor plan. The requirements of a system development project, in my mind, are very much the same as a floor plan. If you didn't have a floor plan, I can guarantee you that in my county in hurricane-prone Florida, that we could not get a building permit. If I said, "It kinda sorta is going to be this big, I'm not sure what this area is going to be, I don't know whether it's going to be covered with a roof," I can guarantee I wouldn't get a building permit. And no construction could start. 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%.

Hello?

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 Quality Plus Technologies e-Talk! with Carol Dekkers as soon as we get back from this short break.

Hi, welcome back to Quality Plus e-Talk! This week we're having what I would call the essence of a virtual interview. This is, when we're in computers, I know that technology is never fool-proof, and people are never fool-proof, and one of the things that I've realized is that today we're really taking an interview to the "extreme," and we're having a virtual interview. So I guess that's something a little bit interesting, and as a host, it's very challenging. It's something that I have to learn, gee, what if my guests don't phone in? So we're going to talk about Kent Beck and Ward Cunningham, rather than with them, but that's okay. And I have a caller. Danny?

Caller: Yes.

Carol: You had a question for me.

Caller: Right. I've been reading some about extreme programming, and it strikes me that the different elements of it don't seem to be really closely related. And some of them are more controversial than others. So you'll talk about the pair programming. I personally think that's a good idea. But some people will kind of shy away from that, the idea of putting everybody in a room together with no walls and all of that, you know, certainly goes against the idea of peopleware and giving them their own office. So some people might want to reject some parts of it. And is that okay? Can you pick up some pieces of it and call that extreme programming or call that a good thing to do?

Carol: Well, one of the things I think that's a very good question. And I think that with backgrounds of engineers, computer scientists, by and large, and then two-year degrees, and we've really got a mix in software of all different backgrounds. We have the traditional structured math majors, engineers, computer scientists, software engineers. And then we have the liberal arts people who have backgrounds in French, in music, and all sorts of things. And they're all thrown together in programming. And I think a lot of times what happens is people don't want to change a lot. The older programmers really don't want to embrace XP. Some of them do, because of what they think XP is. I've heard from one of my colleagues who's doing a review of Kent Beck's book, he had heard and read on the Internet a lot about how XP is just anarchy. Where you just kind of do whatever you want. And I think that really fits into what you're saying, Danny, that it kinds of looks from the outset that, oh gee, you either have to embrace XP entirely in order to do it properly, or don't do it at all. And I don't think that's the case. I think that you can pick and choose the pieces in XP that will work for you, and you can have a very successful project. One of my examples...I did some research with Software Quality Engineering before I developed my Extreme Programming presentation for ASM, and there they actually did a modified XP project. They didn't embrace everything in XP. It was just too much to embrace, and at the onset they picked and chose pieces of XP that would work for them and achieved outstanding success with some of their new Web site applications.

So I think that you can pick and choose the pieces that will work for you. Forcing people and saying, "You must pair program with that person that you don't like, just because XP says you must," I think is foolish. I think that you have to take it with a grain of salt and say, "Let's take the pieces that will work and let's reject those pieces that may not work in our environment." Does that seem to make sense, Danny?

Caller: Yeah. It's a good idea any time you're implementing any kind of a new process, like software inspection is one example I've seen, where there are the zealots like Tom Guild who say you've got to do it all this way or it's not going to work very well. But the approach that I take is more incremental. Let's take one step. Let's take one really good part of it that makes sense to implement and try that. And you just take the incremental approach and don't throw the whole thing out because you don't like one part of it. And I'd be interested to hear if anybody else has rejected the whole thing because of one really controversial part of it.

Carol: And I'll give the toll-free number out again, so that we could...You're welcome to stay on the line for a little bit, Danny, we may have other callers who might want to interact. It's 866-277-5369. And I think you're very right, that when the Yourdon method, when the structured analysis method came out, everyone said, "You must apply it exactly this way." And it was almost to the extent of having police, you know, structured analysis police. And I think that the notion of extreme programming police is something that just doesn't exist. And one of the neat things about talking to Kent Beck live is that you find out that he's a real person. You find out that he's a person that has taken a look at Extreme Programming, he's taken a look at object-oriented programming, and picked out the pieces that really seem to make sense. Not spending too much time iterating and iterating and getting the words exactly right in requirements. Actually starting to do them. So I think that makes a lot of sense. Danny, have you tried extreme programming at all?

Caller: No, I really haven't had the opportunity to follow it yet. I'm still waiting for the right moment to really jump in and try it. But some of my colleagues, there was one for example that said, "You've got to try pair programming. You've just got to do it." Once he tried it, he insists on doing it that way. Anywhere he does any programming. So there's certainly some elements that I'm willing to try. My background is more in 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, this extreme programming, yeah, I knew it was crap." We don't want to be in that situation, but there are so many gains that can be made from it.

There's a lot of writing that's going on in terms of who's writing about XP. And if you go onto Ward Cunningham's Web site, which is C2.com, you can browse through it and find out who's doing the writing. There's a lot of different links to a lot of different places. Industrial Logic is one of the companies that's actually doing a lot of training and consulting in the XP area.

We were talking about metrics. XP is hard to explain in just a couple of moments. And anybody who's listening who has done XP is probably already bored to tears, and they say, "Well, gee, we're already doing that." Well, what kind of metrics are in place? And one of the threads that was in the e-group back in December, which had about 60 postings, so that's about a normal day's worth. But it actually spread across two weeks. It was "Metrics to prove XP works." And the answers that came up and the things that people posted were very very interesting. Ron Jeffries, who is one of the three extremos, moderates the site and will interject whenever it makes sense to do that. And one of the things that he said is that...somebody wrote in and said, "We're planning on piloting some XP projects at work, but we continually run across the question that we can't seem to answer effectively. How will you quantitatively show that XP is an improvement over more traditional methodologies, such as iterative waterfall?" Well, number one, I guess my question would be, "What's to prove that the traditional waterfall works?" We've been using that for years, but what's the proof that that works? We know from the Standish study and a number of different studies that have been done, where we find out that programming today does not deliver valuable software. It's not usable. We don't quantify that. Ron Jeffries' answer, which was a little bit flip, or some of you may think it's a little bit flip, he said if you were considering adding more testing to a team that didn't do much, would you be looking for metrics? If you thought that better manuals would make the customers happy, would you do metrics? Or is the question about metrics really someone's question about something else entirely? And I'll come back from the break with a few more illustrations of what people think we should be measuring and what we shouldn't be measuring and give you an opportunity to participate in a new study group on XP. So I hope you'll join us after this short break. Welcome back to Quality Plus e-Talk! We're having a virtual interview with Kent Beck and Ward Cunningham. And it's easier when they're actually here live, but hey, we're doing okay and I'm channeling. That's what I'll say. I'm channeling Kent Beck and Ward Cunningham as we speak. So this is really a psychic hotline type show. What do you think? The toll-free number's 866-277-5369, and we were starting to talk a little bit about metrics. And as I said, there was an entire thread going on the e-group, Extreme Programming e-group. And Kent Beck talks a lot about metrics in his book. One of the things he says is that the basic XP management tool is the metrics. For example, the ratio between estimated development time and calendar time is the basic measure for running the planning game. And the planning game is when you sit down with the users and scope out on CRC cards, which are a basic premise of XP. You come up with these index cards, and you actually put story pieces on these index cards that you put up on a bulletin board so that everybody can see the extent of the overall system. Even from a regional planning game perspective.

Now, one of the things that's talked a lot about is something called project velocity. And one of the things I found doing a lot of research on Extreme Programming is that Extreme Programming like anything else has its own terminology. It has its own terms, terminology, acronyms. And if you go onto the e-group Web site, you'll find that very quickly you'll start panicking, you'll say, "Gee, I didn't know Ruby was a language, I didn't know this was a language. It's quite interesting." So the project velocity is a ratio that is, it means the team processes, if your velocity rises, if you're doing good in terms of velocity, that means that you're developing things quicker. And all you need to develop velocity is story points done over time. All you need for task tracking this is time-in versus time-to-go for each task. So when you think about this, velocity is really, when you take a look at the ratio of estimated development time and calendar time.

Now, traditionally for a lot of companies that have been tracking metrics, they've been tracking things such as productivity---how many lines of code can somebody develop over time? Well, that doesn't really work, because if you insert somebody to develop lines of code, what are you going to get? More lines of code. What about function points? Would function points work? Which, function points is like the square feet of software. Can we use function points on stories? Well, yeah, we could. We could definitely use it on use cases, we can use it on stories. We can probably do better, though, in tracking the number of changes to a story. How many times did this change in this particular iteration? How many times did we have to refactor code? How many different stories are actually developed? How many times did we have to go and redo tests? That type of thing. There's a lot of different things that we can start taking a look at in the Extreme Programming area.

And I'd like to extend to you, if you're thinking about starting XP or if you are in XP, that we'd like to form a study group on StickyMinds.com, where we'd actually like to have companies who are working with XP, who have started working with it, who have had successes and failures, really have an interaction where we can start focusing on what are the good metrics? What are the things that we should be capturing? Because the traditional metrics, things like defects per line of code, aren't going to have any place when you're taking a look at XP programming.

So we need to take a look at those types of things. We need to take a look at the number of tests that you could run successfully. How many tests did you have to develop? That type of thing. And we really want to focus on business value. A lot of times, Howard Rubin and some of the people that are strong gurus in our industry, have talked about focusing on business value. Well, that's one thing that really gets amplified in Extreme Programming. Because you're sitting and working with the customer. Because you're sitting side by side, looking at things, prototyping. When you have a problem, they're right there. As you're moving through and you develop your tests, before you actually do any programming, as you're developing your tests, and you say, "Well, I wonder what would happen if this came up?" Rather than having your users in a building somewhere over in another city, or in another building somewhere, you actually call them in and you say, "Well, what happens when this comes up?" And oftentimes, the users may say something like, "We didn't think about that." So you have actually an iterative story time right then, when you flesh out some of the things that you may not have thought about. Now think about it in traditional development. Oftentimes, I've seen system requirements specifications that have been up to 600 pages long. That have had detail after detail after detail about the requirements. And yet they weren't testable requirements. Yet there were ambiguous things. There were a lot of "or or or's" in the requirements. How do you test an "or or or"? You can't. And you find that out at the very end of the lifecycle. What's interesting about XP is developers become testers become developers. They're the same person doing both. And what will be interesting is to talk to my guest next week, who is Bret Pettichord, and he's written a book, or an article, on testers and developers thinking differently. And we'll be back to talk a little bit more about that, a little bit more about XP, shortly after these messages.

Welcome back to Quality Plus e-Talk! with Carol Dekkers. We've had an enjoyable hour doing a virtual interview with, I'm not sure if it was all three extremos, or two of them or just one, but we've been virtually interviewing Kent Beck, Ward Cunningham, and since it's a virtual interview, I can say we virtually interviewed Ron Jeffries as well.

Before we went into break, I gave you an offer that StickyMinds.com, we're going to set up a study group, where if you're going to participate in XP or you're thinking about getting started in XP, or you just want to be able to sit on the sidelines, try a few things, see if it works, see what doesn't work, we're going to set that up so that we can actually start collecting metrics, start changing metrics, start actually working with XP and making it work for your organizations. So it's really to minimize the risks for your own organizations. You'll learn a lot about the XP lingo, things like system metaphors, incremental delivery, refactoring, spike solutions, extreme, XP design, lazy optimization, that type of thing. And it'll be very interesting as we essentially learn together and figure out what are the metrics that make sense? That's a challenge, with anything new people say, well, we need brand new metrics. Well, one of our challenges is to figure out if rxtreme programming is really the way to go. If your company has sat back and said, "We're not sure if it's the right time to jump in. We don't know if we can risk it." Well, I'd kind of put the question to you. If you have between three and ten developers that are going to be on a project. If you have kind of Jell-O type requirements, if you're not entirely 100% sure that you're going to make it, or that you have a history of poor development, poor history in terms of getting your users to be involved, if you have a poor history of on-time development, if you have a history of really not being able to manage well, then I'd say give XP a shot. What's the worst thing that could happen? Your users participate. And if you get halfway through the project and you say, "You know what? This isn't working. Let's go back to traditional." You haven't lost anything.

I'm going to finish up with one of the quotes that Kent posted on this thread. It was "Is CMM mindless regimentation?" And there were a lot of opinions. Capability maturity model providing a structured method. And actually structuring your processes, so that they're repeatable, so that they're measurable. And somebody said, "Is CMM mindless regimentation?" And they asked that of Kent Beck.

And he said, from what he's read, chaotic approaches sometimes are more effective. I can't say that I'd necessarily agree with that. For instance, in one report that I've read a long time ago, it was said that for companies on a survival track, the chaotic approach was more successful as a survival strategy than a well-structured and organized track. In that case, I think I'd probably agree. In terms of, if you are on a survival, you must get something out today. Absolutely, positively. To spend the day planning probably isn't going to get it out the door. So you might need a radical approach. You might need to do something different. And the pair programming has proven itself, it works extremely well. The story games, planning games, have proven themselves to be worthwhile and extremely valuable. One of the first places that you might want to go and take a look at is the "Extreme Programming Explained: Embrace Change," which is Kent Beck's book. Again, it's called "Extreme Programming Explained: Embrace Change". It's a very easy read. It's a very good read. It's very structured, it all hangs together. Which might be a surprise to some of you. Next week's guest: We're going to be talking to Bret Pettichord, who wrote "Testers and Developers Think Differently".  And when I first read it, I thought, "Hmmm, I wonder if they're really these different, evil twins?" Whether it's really one personality that has schizophrenia. But we're going to be talking to him about the difference between testers and developers, why or why not they should think differently. And I hope you'll join us for the rest of this series. We'll be having Tom DeMarco, we've recently lined up two absolutely phenomenal standards experts, Peter Voldner and Stan Magee, who are writing a book on standards. Now, it may turn you off. You might thing that ISO standards, "Gee, gosh, that's a boring topic." They're going to be talking about taming your process with standards. And really picking the ones that will help you in your processes in developing better software.

So I thank you for joining us today. I'd like to thank you for being part of this virtual interview with Kent Beck and Ward Cunningham. I'd like to thank you for the virtual call-in, in some cases. I'd like to thank Danny for phoning in. I'd like to thank our sponsor, StickyMinds.com, and I'd like to invite you to go to our Web site, www.qualityplustech.com, where we've got free articles, measurement information, and everything else you might want to see.

Have a wonderful week. I'll talk to you next week.