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

TEXT TRANSCRIPT: 5 December 2000
Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.

Announcer: Welcome to Quality Plus e-Talk! with Carol Dekkers. 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 Carol Dekkers.

Carol: Hey, welcome to the show. I'm Carol Dekkers. I have as my guest this evening another person who has really taken the world by storm, and is one of what people like to call "The Three Extremos." I think the same caliber as one of The Three Tenors. I'm very pleased to have Kent Beck on my show. Let me give you a little bit of background about Kent. He's a programmer. He's best remembered for pioneering patterns for software development, the rediscovery of test-first programming, the J-unit testing framework, and most recently, for eXtreme Programming. He's the author of a fairly recent book called eXtreme Programming Explained: Embrace Change. So, welcome to the show.

Kent: Well, thank you very much. I haven't ever been interviewed on radio before, so I had to get over my urge to dress up. But I'll do my best here.

Carol: And this week, you're actually in Santa Cruz, doing something I thought was very interesting, called an XP immersion class.

Kent: Yeah. We take a week, and take a group of about 30 programmers and 10 or so business people through the experience of doing extreme programming, soup to nuts. So they do a little project, and they get a chance to practice all of the various techniques involved in XP, and oftentimes experience the emotional changes that go through-despair and exhilaration and triumph, and so on. Hopefully, if we get those in the right order, then they recommend that other people come to the class.

Carol: It sounds a little bit like traditional programming, that there's despair, there's hope, there's joys, there's fears, and life in general. For our listeners, maybe you could share with us…What really would you say encapsulates extreme programming? What is extreme programming in two minutes or less?

Kent: Well, if you imagine you were a customer for a piece of software. And imagine further that you could write down all of the features that you wanted that software to have. And let's say you wrote those one per index card. Now, what you could do…And one further simplifying assumption that won't kill our model, but for the moment…Imagine that your team can implement one of those features every week. So if you wanted to know how long the software would take, count the cards. Okay, this is 26 weeks because I have 26 cards. Every Monday you could come in, and you could look at the cards and you could think, well, what is most important to me? What would I like the team to work on this week? You pick the card that's most important, you hand it to them. On Friday, you'd have that feature added to the rest of the system. And then you continue like that. The advantages from the business side is that you can change your mind midstream, you can be sure that the team works on the most valuable stuff first, instead of messing around with pointless technology, and the team doesn't complain when the requirements change. I hate that word "requirements."

Carol: Right.

Kent: You know, if you have a set of requirements and you build a system, and it doesn't do all the requirements, you generally still get paid unless you really screw up. So the dictionary definition of requirements is something mandatory or obligatory. So apparently, they're not required. It's more like wishes.

Carol: I think in some cases that's the case, that…And we sometimes as an industry get caught up in the terminology. And extreme programming, from what I've seen, has its own set of terminology as well.

Kent: Well, where there was a concept that fit precisely, we certainly use it. But where the concepts weren't…Where we wanted a concept with a little different flavor to it, we borrowed words from elsewhere. Like the word for the features that we use in XP is "stories." And it's emphasizing the role…At the level of planning, the role of the business person is to tell stories about what the system ought to do, and the role of the programmer is to listen carefully to those stories. Now, picking that word "story," I was trying to emphasize this idea that we're talking about a human, social process. This isn't requirements capture, it's more like this thing that's been going on for 10,000 or 20,000 years around the campfire, where the important things get passed from one person to another in the form of stories.

Carol: Would you say that stories are the same as rational loads, or use cases?

Kent: No, I don't think they are at all. The most important difference is political. Any time you introduce a complicated piece of technology, you create a group of political haves and have-nots. So you have the people who know how to run the tools, suddenly have power in the project. Unfortunately, the skill to use those tools, or the desire to learn to use those tools, is completely orthogonal to the ability to actually make decent decisions. So use cases, not in concept but as I see them practiced, become something that's very technical. And the programmers typically are the only ones with the patience to figure out what all the different sections are, and what format they should be in, and how to use the tools. So all of a sudden, you have all these programmers running around, making what are essentially business decisions.

Carol: Right.

Kent: So the biggest difference between stories and use cases is one of the balance of political power. Practically speaking, they're quite different also. The use cases oftentimes, early on in the project, gather a lot of detail, and the stories gather detail rather more slowly. At first, it's just a name and an estimate on a card. As time goes on, maybe they'll get a little more detailed, and it's not until one of those weeks in which that story is picked that the rest of the detail gets fleshed out. And at that point, it becomes much more detailed than a use case, because you drive it all the way down to actual automated test cases that will demonstrate the presence of that story in the system.

Carol: Now, one of the things that I've heard, that was given to me as an analogy of what XP is really intended for, is that if I want to go from Santa Cruz to Tampa, and my user, or the person that's defining my trip says, "You must go from Santa Cruz to Tampa." And in traditional development, we'd sit down and we'd chart out, essentially using the AAA Trip-Tiks or something, exactly where we're going to go, where we're going to stop every night, and it's going to keep going like that. And when we finally finish that, and we get in the car, you say to me, "You know what? Chicago is great this time of year." Is that similar to the types of changes that happen in XP perfect projects? The types of things where you really say the requirements are just changing all over the place. Nobody has any idea what they want until they see what they don't want. Are those the things that are really perfect for extreme programming?

Kent: Well, certainly as the frequency and violence of changes increases, it's more and more valuable to be able to deal with that, those changes, gracefully. If you had absolutely fixed requirements, and you had perfect engineering knowledge, there's probably some more optimal way than XP to schedule the engineering of that task. But as the frequency of the change goes up, and the frequency of the change in the technology goes up, in other words, the more you learn, the more you want to be able to plan, to make all sorts of decisions, not just to…planning decisions, estimation decisions, analysis, design, implementation, tools, technology decisions, as you go instead of making them all at first. The kind of projects that I'm involved in, people are really ignorant at the beginning. And yet there's this notion that you ought to be making, you know, if only you were a good programmer, you could make all your decisions there when you were stupid. It doesn't make sense to me. It makes much more sense to be able to say, "Oh, I see. The design of the system should be like this." And then things would be simpler, and then you change it. Whether that's a month into the project, or ten years into the project. You should be able to take what you learn and put it into the system. That makes the system that much more capable for the next thing you need to do.

Carol: Right. One of the things that people have said to me is that their first impression of XP is that it's almost, in some cases, anarchic. It's the reason…It's justification for the programmers to say, "You know what? We didn't want any of that process stuff. The CMM stuff. That's just too much overhead. Let's just abandon all that and go back to just coding and fixing directly." And I don't think that's the case. But I wanted you to be able to respond to that.

Kent: Well, it certainly…One of the things I've discovered about XP is that it really… People see their fears in it, oftentimes. So the programmer's used to a lot of freedom, looks at it and sees, "Oh yeah, I have to write tests, and I have to program with other people, and I have to deliver early and often, and so I can't do all this pie in the sky design that I enjoy so very very much. So they see it as being lots and lots of structure. And the people who are used to very…processes from a more mechanical mindset, see it as total chaos. It's just programmers running around and doing stuff.

Carol: Right.

Kent: And the thing that makes it…There's a couple of rules, very simple rules, that make it not just anarchy. One of which is that you have to write tests before you write functional code. And the second is that you have to continually refactor the design.

Carol: And we will continue on that line in a few moments, after a few words from our sponsors, with more of Kent Beck.

And we're back with Kent Beck, who is one of the fathers of extreme programmers. And Kent, before we went into the break, you were talking a little bit about refactoring, and the two changes, or the two differences that you see that extreme programming really stands out. Did you want to explain a little bit more about that?

Kent: Sure. There's…Refactoring is the process of taking a running system and changing its structure. So a very simple refactoring is if you have a long function, and you notice there's some piece of it in the middle that is loosely connected to the rest of it, you can make that into its own function, and call that, and make the original function shorter, and oftentimes clearer and easier to understand. So that's a simple kind of refactoring. But you can change the structure of any reasonable structure for a program into any other reasonable structure, in terms of a handful of those kinds of transformations, where you're taking objects and splitting them apart and merging them together and moving code from one place to another and moving variables from one place to another. Martin Fowler has a really nice book called Refactoring, which gives you the catalog of these transformations. And the way we use that in XP is that you begin, so you're working on this one feature, let's say, in a week, and so you say, "Well, if this is all I have to do, I can design this very simply." So, that's how you design it. Well, that enables you to give the businessperson, the person who's paying your salary, let's remember, a lot of feedback about what's going on. Well, the next week comes along. There comes another story, and it's in a similar area, and you look at the design of the existing system, and you say, "Oh, my goodness. That was so naïve. How could I have done something so simplistic? Now I have to change it. So you use these refactorings to, in a very disciplined way, grow the design of the system in a new direction, so that the next story fits in nicely.

Carol: And is it similar or different from creating subroutines, like we used to use in traditional development?

Kent: Well, that's one of the simple examples of a kind of refactoring. But it turns out that there's maybe 20 or 25 refactorings as an objects programmer that you just use all the time. An example…A client of mine, Avant, in San Francisco, is going through right now is they were generating HTML inside of their Java code, and they realized that it was making it difficult to change, so they're gradually moving more and more toward using XML, and then using the XSL transforms to generate the HTML. So the whole time they have their Web server up and running, but little by little, more and more of the HTML is getting generated by these transforms instead of directly by the Java code. So that's a very big refactoring. It's an architectural refactoring. But it's still done in little pieces.

Carol: And as you go through and you change these constantly, and you build little bits of code, when there needs to be a change, as invariably happens, you know, change is just the natural state, as far as I'm concerned, people don't get quite as defensive as if they've spent months working on a series of code and then somebody comes in and says, "No, no, no. I don't want that." It seems to be a lot more flexible, that users can change their minds. Users can be part of the process, as opposed to on the other side of the wall.

Kent: Well, sure. And you know, you've got two weeks, is a typical iteration length is one, two, or three weeks. And you don't do just one story in that amount of time, you do four or five, you size the stories appropriately, so that the team can accomplish that much. While you're in the middle of doing that, you say, "Well, you know, there was this great trick I learned in school. I can imagine needing it someday for this. But in the context of this story, right here, for these two weeks, I'll just do this simple thing." Well, a week later or a month later, when the time comes to do something more sophisticated, you look at the code and you don't have ego involvement. That wasn't the last word. You weren't trying to program for the ages a month ago. You were trying to get that iteration's stories done. And now the time has come to do something that's a little bit more sophisticated. And it feels good. You get to pull the tricks out of your bag once in awhile. But most of the time, you're getting away with doing really quite simple systems.

Carol: Interesting. Now, one of the things that comes up that I think has received a lot of pushback is this idea…It's either embraced, or it's pushed back…Is this idea of programming in pairs, that you…If you're on an XP project, you as a programmer have to have somebody else working alongside of you.

Kent: So here's the rule the way I state it. That is, all production code is written with two people at one computer. Now, you know, I'm not such a young guy anymore. I can program maybe four, five hours of really concentrated work a day. And so for that amount of time, I'm paired up with somebody. What you find is that you make far fewer mistakes, and you always have somebody there when you're a little bit afraid to tell you hey, it's okay, we can get through this.

Carol: We'll talk a little bit more about programming in pairs, and more about extreme programming after these messages. And we'll be back.

Kent: …..be tactical and completely focused on being tactical. You don't have to worry about, "Am I missing something big?" And the person sitting next to you is looking at the big picture and saying, "You know, you're about to do this thing. But there's this whole other approach that could just make all of this go away entirely." So, you know, when your partner spots that you're kind of going down a rat hole, they'll start feeding you helpful suggestions, which get so annoying after awhile. So you shove the keyboard over, and you say, "Okay, smart guy. Name that tune. Show me what you're talking about." Now, the roles switch. They become tactically oriented. "How am I going to accomplish this thing?" And you are starting to think strategically, but at the same time, you have a lot of motivation, because this person just stepped on your good idea, so you want to have an even better idea than they do. And the keyboard's flying back and forth every couple, three minutes. It's not like watching someone program. It's more like having a very dynamic conversation about your program, and you get the experience of programming at the same time.

Carol: Are people forced…When you program in pairs, it's not like in school, when you 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 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 that it really picks up from the best practices in the past and combines them into something that makes a lot of sense.

Kent: Well, the intent is certainly that, although you can look at individual practices in XP and say, well, that's naïve, how could this test-first programming stuff give you decent quality? There's other practices that support the weaknesses of any individual practices. So that the whole becomes more than the sum of its parts.

Carol: Right.

Kent: I would say that Jim Highsmith's adaptive software development is kind of the manifesto for a whole community of people who are all looking for ways of focusing people on programming, instead of programming on people.

Carol: Now, one of the things I think…There's always danger. What would be the biggest danger? If a company was saying, you know, I kind of like what I hear, they go out and they buy your book, they like this whole process, they get involved in some of the Web type things. What's the biggest danger that they can encounter?

Kent: I think really, it's the social…It's more the relationship between business and development. It's…If you're producing something on a very regular basis, you're producing business functionality on a regular basis, you can tell 25% into a project whether you're going to on the final day have as much stuff as you expected. One third as much as you expected, or three times as much as you expected. Well, there's lot of organizations that punish that kind of honest feedback. And so the biggest dangers, I think, are that you bring XP in, you start using it, the information will start to flow, and people will flip out because they just don't know how to deal with honest feedback.

Carol: Right.

Kent: There's a danger if the techies get ahold of it. And use it as a stick, and say, "Hey, back off. We're extreme programming now." …Somebody who said, "Well, my supplier went to…said they were adopting extreme programming, and from my perspective, the only thing that changed is I stopped getting documentation." I just think there's a little bit more to it than that.

Carol: Oh, I just conjured up this vision of these techies standing with their laptops between them and the business community and saying, "Fend off!"

Kent: Kind of Ghostbusters. "Back off! We're scientists!" And that can certainly happen. XP is about a conversation between equals. It's business and development having a conversation that they both have a different perspective to bring to, and neither can impose their will on the other. So if you say, "Look, this is going to take six months." And the business person says, "I have to have it in three months," the programmers should say, "Which three months would you like first, sir?" "I have to have it all!" "We understand that, but in the meantime, which three months would you like us to work on first, sir?" And one of the things I like about XP is that is gives…Programmers sometimes are really beaten down, right? They're told that if only they were better, they could meet their estimates, and all this other stuff. And they feel oppressed, right? They feel frustrated, and XP gives them…You're making lots of estimates, you're tracking lots of actuals, you have all kinds of data to say, "Look, what you're asking for is simply impossible. I'm not going to sign my name to anything that's simply impossible. You're going to have to make a business decision about which three months' worth of this stuff you want."

Carol: Right. Now, for people who want to know where to start, I think that your book is one of the best kind of basic primers for anyone who wants to know anything about extreme programming. Would you like me to give out the ISBN number for it, so people can find it on Amazon.com, or…?

Kent: Sure.

Carol: Okay, it's called eXtreme Programming Explained, and the ISBN number is 0-201-61641-6.

Kent: There are two other books that have come out recently. Planning Extreme Programming, I wrote with Martin Fowler, which is for project managers. And Ron Jeffries, Ian Anderson and Chet Hendrickson wrote Extreme Programming Installed, which is more of a practical guide for putting it into place, and I'd recommend both of those also.

Carol: And we'll be back to wrap up after these short messages.

I'd like to thank my guest this week, Kent Beck, who has spent his last hour with us and talked a little bit about extreme programming. Kent, in 60 seconds or less of extreme time, what would you like to give our listeners as a sendoff?

Kent: Well, I'd like to talk briefly about how you get started with this. You don't have to drink the whole glass of Kool-Aid all at once. The thing that programmers can do is get some kind of a simple testing framework. I have an open source project called J-Unit, that Eric ……. and I run. And try this test-first programming thing. That's…It'll take you an hour, a couple hours, to get set up and write your first test. At the end of the first day, you'll have some feel about whether that's going to help. And on the project management side, so many projects that I talk to just have no idea of how much stuff they have to do. So, write down or get your customers to write down, the things that they want, on index cards. Write down estimates on each of the cards, do the math, see how things stand. Those are two very simple things you can do, very small investment, quick payoff, and they set you on the road to really turning up all the knobs to ten, and getting a lot more benefit.

Carol: Right. Do you have a Web site you'd like anybody to go to, or that you'd like to give out, if anyone's got comments or questions…

Kent: xprogramming.com is a real good place to start. It's run by Ron Jeffries, and it's got a lot of basic information. There's another one, extremeprogramming.org, which Don Wells runs, that's also got public information. And either of those places will give you links to all the other stuff that's going on.

Carol: Well, I'd like to extend a great thank-you for being our final guest on this series of shows. It's been a lot of fun.

Kent: Thank you.

Carol: And for our listeners, I'd like to tell you that we're moving to a new time starting January 4, 2001. We're going to be moving to Thursday mornings from 10 to 11 a.m. Phoenix time, and Internet broadcasting simulcast through the real audio, which will be 12 to 1 o'clock Eastern Standard Time, and anyone else, anywhere else, that's listening to us, it's 10 'til 11 Phoenix time, starting Thursday, January 4. We've got some exciting things lined up. We've got really interesting guests who will rival some of the guests we've had. We…In the last 13 weeks, we've had Howard Rubin on cybergeography, we've had Heather Winward, who talked about handwriting analysis and team building in the information technology area. And if you've got any comments on future shows that you would like to see, if you've got any comments on format, ideas, that type of thing, just shoot me an email at [email protected], and we're looking forward to talking to you more in the new year, with more of Quality Plus e-Talk. Meanwhile, from me here in Florida, I hope that everyone has an absolutely wonderful holiday season, whatever your preferences are, or whatever your religion is, or if you don't have one, I hope that the new year finds you with a lot of happiness, joy, and a lot of optimism in extreme programming, in looking at the future of software development. Kent, I wish you an absolutely wonderful holiday season. I know that in Oregon, you'll probably spend the holidays whitewater rafting.

Kent: Skiing, perhaps. The same to you and yours. Enjoy your vote count.

Carol: Yes. I hope that when we return in January that the votes will be counted, and counted again, and counted a third time, and we should have a winner by then. So from Carol Dekkers, and Quality Plus e-Talk, have a wonderful holiday season. We'll see you in January. Again, January 4, 2001, starting Thursday, 10 'til 11 a.m. Phoenix time, 12 to 1 Eastern Standard Time. Good night, and have a great holiday.

Copyright 2001 Quality Plus Technologies and Carol Dekkers. All rights reserved.