Interview with Ron Jeffries, Ann Anderson, and Chet Hendrickson

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.