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

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