Home > Articles > Software Development & Management > Agile

Interview with Ron Jeffries, Ann Anderson, and Chet Hendrickson

  • Print
  • + Share This
Extreme programming (XP) is becoming a very popular model for building applications. In this interview, XP experts Ron Jeffries, Ann Anderson, and Chet Hendrickson explain how the principles of XP can apply to more than just programming.
Like this article? We recommend

Like this article? We recommend

Question: Why did you decide to try extreme programming (XP) on a real project?

Chet: We chose to do XP because we had failed miserably using a more mainstream OOA/OOD approach and we had nothing to lose. We brought Kent Beck in to help [with] performance tuning and he found a zombie project; it was dead, but didn't know it. XP gave us a way to get back on track and to demonstrate to our customers and our management that we were staying on track.

Ann: I don't think I decided to use XP on a real project. I had heard about what the C3 (Chrysler Comprehensive Compensation) team was doing, and I tried to convince the manager of the project I was working on to try some of the things they were doing. All I really wanted to do was automated testing. My manager told me automated testing was too expensive, and we didn't have time for it. I think that was when I decided I would really rather work on a different project. Eventually, I joined the C3 team.

Now, when I think about joining a project, the method they use is one of the things I consider. I have worked on failing projects and I have no desire to repeat the experience. I think XP can help make projects successful, so I prefer to work on projects using XP.

Ron: I had had a bit of grounding in Kent Beck's practices through a tutorial I took from him and some subsequent email. They resonated with my own beliefs, and made sense. Little did I know at that time how extreme, and how powerful, his ideas were.

Question: How do you "install" XP in an organization?

Chet: There are two basic ways to install XP. On the C3 project, the developers, the customers, and all of our management bought into the process, so we took the practices on faith until we saw that it all did work. The other way is to slowly introduce the practices one at a time until the project is doing everything. I would recommend starting with testing, continuous integration, and the planning game.

Ann: The short answer is, buy our book—it gives you all of the details. A longer answer is that there are two ways to install XP in a project. One approach is subversive—don't ask management for permission, just start doing the practices. The second approach is to have permission and support from both management and the development team—and then start doing the practices. I have no way of knowing which approach would work best for you or your company.

Ron: For a group to go "full XP," the desire has to be there. If there is resistance to any process, the process won't take. Once you have the commitment, there is another choice to make: Will you try to do all the practices at once, or will you start with whichever one will give the biggest benefit (or with your biggest problem) and add them in sequentially? I enjoy working with teams that want to do it all. It's not disruptive, and the learning goes quickly. The team gets benefits from all the practices, even early on.

Question: Why is XP so popular around the world?

Chet: Mostly because it works.

Ann: XP is popular because it gives people hope. By following the practices of XP, they can make their projects successful. Too many software projects fail—and the emotional and financial cost of those failures is huge. The message of our book is that it doesn't have to be that way.

Ron: I think it appeals to programmers who feel there must be a way to strip away the heavy processes and get to the essence of providing software that people actually want. It appeals to customers and managers who are looking for a way to have a sense of control over their projects, and who are looking for a better way to get what they need.

Question: Why did you decide to write a book on XP?

Chet: Kent's book had just come out and we saw the need for a more detailed look at how you bring XP into an organization—and we couldn't think of anyone with more experience at doing XP on a daily basis than us.

Ann: Uh…I did it for the fame? Or was it the money? Or maybe it was for the groupies?

Ron: We had had a great experience on the project we did together, and wanted to share that with the world. And of course we were hoping for fame, fortune, and to be allowed to play ourselves in the eventual movie.

Question: How does XP compare to traditional software methods like the SEI's PSP or Rational's RUP?

Chet: XP is a lightweight process. It's designed to be [the] least methodology that could possibly work and it's targeted toward projects of a certain size and shape. The ones you have mentioned are designed to be all things to all people and as such are much heavier than the average project needs.

Ann: I think that the difference between XP and more traditional software methods isn't in what you do or don't do; it's in why. XP is focused on delivering software to the customer on time. It's called extreme programming because programming is a really important part of delivering software. Everything we propose doing in XP supports that goal.

Ron: If you did PSP, you would know a lot about your software development skills and process. I'm not at all sure that you would get any more software done. Part of what's good about XP is that it involves a lot of programming—which is what programmers tend to like—and it does it in a way that gives the customer control over what gets done, and a clear sense of quality.

XP is what we call an "instance" of RUP. That is, RUP is a set of general guidelines for creating a software process, and XP is a specific software process that's consistent with it. Some people disagree with that, choosing to interpret RUP as requiring a lot more paperwork than an XP project typically has to endure. Certainly RUP and XP share a focus on an iterative, incremental approach to developing the product.

Question: Was writing anything like you thought it would be?

Chet: We didn't know how to write a book, so I don't think we knew what to expect. The process we were using at the end was very different from the one we started with.

Ann: Writing was nothing like I thought it would be. It was both better and worse than I ever imagined.

Ron: Writing the book turned out to be harder than we thought. We produced twice as much material as we needed, and went through about three different organizations for the book. It was really fun and I'd like to do it again.

Question: What background and expertise did you bring to writing this book?

Chet: Our project was the first to do all of XP. In fact, the process didn't have a name until quite a ways into the project. We have the most experience with XP, not only when it's running smoothly, but also when it's going off track. We're able to show how the theory can be turned into practice.

Ann: I have a degree in computer science and engineering. I also have over a decade of experience working as a software developer. Some of my projects have been successful; some haven't. Fortunately, I'm willing to share what I learned.

Ron: Modesty forbids. Well, okay—I've been doing software since about 1962, and have had the luxury of working all that time on new and exciting problems and technology. Over that time I've made many mistakes, and have learned from them after the first few times. The most exciting thing that I've ever done was to learn XP from Kent. It brings together things I've always believed and things I never understood, in a way that seems to me to make success in software much more likely. I'm enthusiastic about it, and wanted to share it with the world. And there was the movie thing.

Question: What one thing do you want software developers and organizations to take away after they read your book?

Chet: That there is a better way, one that's predictable and repeatable, one that lets your customers get what they want and lets your developers live normal lives.

Ann: I think software developers and organizations will have an understanding of what XP is, and how they can make it work for them.

Ron: There is a better way. And it's not harder or less fun. It's more fun and better for customers and programmers alike.

Question: What are your plans for future projects and books?

Chet: I'm collecting patterns used in testing, with the idea of putting together a book to help projects test their systems better.

Ann: I don't have any plans for the next book. I'm still basking in the glow of having written Extreme Programming Installed. I'm looking forward to XP (and other light methods) 2001 in Italy. Other than that, my calendar is open.

Ron: I really did enjoy doing the book and would like to do another one. One topic that appeals to me is refining XP: How do you go beyond vanilla XP to accommodate various situations? Another topic that would be very valuable would be a book about XP testing. I'm sure that someone in the XP community will work on that one very soon. We're not sure who'll step up to that one.

Question: What are your predictions for XP in the next few years?

Chet: Over the past couple of years, we've seen XP take hold within the software community—without a lot of projects actually doing XP as a whole. I'm afraid that projects will continue to adopt just some of XP's practices and therefore rob themselves of the opportunity to be as effective as they could.

Ann: I think XP is going to have a huge impact on how people develop software. Timeframes for developing software [are] being compressed, while the complexity of the software is increasing—something has to change. We can't continue to develop software using the same old methods and remain competitive.

Ron: I expect that it will continue to grow. People will try it and have good results, and other people will try it and fail anyway. I think that there's a lot to software development and to product and company success, and no process is a silver bullet. And XP will continue to be controversial. A lot of the controversy, frankly, is from people who don't know what it is and are just reacting to the name, or to our enthusiasm for it. But there are some important questions as well, such as where XP's approach to emergent design will work, and where it may not. We're at the beginning of the lightweight methodology era, and there's still a lot to learn.

Question: What else is out there that compares with XP?

Ron: XP has a lot of mind share right now, but there are many people working in light methodology. Jim Highsmith's Adaptive Software Development is aimed at larger projects than XP addresses, and Alistair Cockburn is working on a family of light processes, of which XP is one high-performance member.

About the Authors

Ron Jeffries, Ann Anderson, and Chet Hendrickson are the authors of Extreme Programming Installed(http://www.awlonline.com/product/0,2627,0201708426,00.html) (Addison-Wesley), 2001, ISBN 0-201-70842-6).

  • + Share This
  • 🔖 Save To Your Account