Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Interview with Kent Beck (circa 2001)

09.10.2011
| 5094 views |
  • submit to reddit

At the Agile 2011 we celebrated the 10th anniversary of the Agile Manifesto. One thing that occurred to me about how to celebrate this was to re-publish abbreviated versions of my interviews with several of the 17 authors. These interviews were published in my 2002 book, Agile Software Development Ecosystems. They reflect the state of the industry and what these founders of the Agile movement were thinking a decade ago. I’ll continue with Kent Beck.

Questioner: “I’m worried about the fact that in XP you don’t do any design.”

Kent: “We do design for a couple of hours each day during an XP project.”
Questioner: “That’s what I’m concerned about—you don’t do any design!”

I sat down to talk with Kent in the lobby of The Lodge hotel at Snowbird ski resort, watching the final skiers of the day cut through two feet of fresh Utah powder. We chatted about the past, the present, and the future of the XP movement. The conversation wasn’t about pair programming or estimating stories; instead, it ran the gamut from his early days as a programmer, to the impact that parenting five kids has on his work, to dealing with life as the leader of a movement that has mushroomed in just a few years.

Jim: What were the historical threads that came together to create Extreme Programming?

Kent: First was my and Ward’s [Cunningham] emphasis on technical mastery. We spent thousands of hours learning every nuance of Smalltalk and then created CRC cards as a way to share some of this experience with less-experienced Smalltalk programmers.

Second was the aesthetics of code. Ward and I shared this aesthetic. We just liked writing code. Even if we were in a hurry, we would slow down even more. There was this sense of a level of engineering that most software engineers don’t even know exists.

Jim: When you work like this, with such an emphasis on the quality of design and code, are you going faster and producing higher quality?

Kent: No question about it, when you operate like this, you are eking every last lesson out of the experience that you have. So you learn a lot faster. You can only have so many ideas; you want to suck as much juice out of each one as you can.

The third thread of XP comes from a feeling of oppression. I thought, I really thought that I was a bad programmer, because I couldn’t estimate. I’ve always kind of been a crusader in that regard, and I’m not sure it’s always been the healthiest thing. But it’s part of your make-up; it’s what you do. Codependence is a great model of the relationship between business and programmers, with business playing the part of the alcoholic. The programmers just say, “If I was a better programmer, maybe they would stop beating me up.”

The fourth thread of XP comes from helping build software teams at start-ups and their need to maintain flexibility. In one place I worked, there was a compiler writer who wrote five lines of test code for every line of functional code. He was writing a Data Parallel C compiler, while another team was writing a Fortran compiler. He would just out produce them. The light went on for me about testing; this whole idea of automated testing and that it wasn’t an idea of an investment but an accelerator button. I’d always seen it as a zero-sum game; the more testing you did, the less time you had to develop code. He showed me that this testing moved the whole curve.

Also, in reading Chaos (Gleick 1987) about the same time, I recognized the echoes in the few rules I’d given them and the emergent behavior that happened, without all the hoohah.

Jim: It’s interesting that so many of the Agile authors have used complexity theory as a conceptual base.

Kent: Well it’s the only way to make sense of the world. There is no centralized explanation of how you ought to behave. CAS [complex adaptive systems] theory has a very simple explanation about how you ought to behave in the world. Find this set of rules and then act on them, measure the results, and tweak the set of rules. It’s very liberating when you really take that in. You don’t have to be in charge of everything, you don’t have to make all the technical decisions. In fact, to the degree to which as a leader you are making technical decisions, you are screwing up the dynamic of the team.

Jim: What next?

Kent: Then came the C3 project at Chrysler, where I tried to be much more hands off. I wasn’t going to make a single technical decision.

Jim: You were trying to create the right kind of environment?

Kent: Yes, Ron [Jeffries] and I. We were trying to set up the initial conditions and then tweak them. No heroics, no Kent riding in on a white horse, which was quite a switch in value system for me. I prided myself on being the biggest object guru on the block. I had to deliberately give that up and just say that’s not what’s going to make me valuable.

Jim: I’ve found that one of the problems with this approach to management is that success often seems almost accidental to people.

Kent: The best manager I ever had was at the Stanford linear accelerator lab. I worked in the control room. This guy spent all his time making Heathkits. Everybody complained about how lazy he was and why he didn’t do this or that. But everything was always on time; if you needed parts, they were there. Personality clashes got resolved instantly. I’ve always wished that I wasn’t 20 years old when it happened so I could appreciate that this guy was absolutely masterful. He kept everything running absolutely smoothly. So that’s my aesthetic as a coach. If I do everything perfectly, then my contribution is totally invisible to the team. The team says, “We did this.”

Jim: What else has contributed to your views about mentoring and leading teams?

Kent: I think being a parent comes into it, too. I have five kids—you learn when you have a larger family by today’s standards just how much stuff really doesn’t matter. That’s how I enjoy them. I have three stages of emergency that I live by. Number one is seeping blood, which I’ll take care of at half-time; dripping blood, which I’ll take care of at the next commercial; and spurting blood, which I’ll get up off the couch and deal with immediately. And seriously, some of that imperturbability helps me survive large clients where people yell and scream. I just chill out, and I can get through it.

Jim: What is your long-term vision?

Kent: Growing a vibrant community around XP is probably my number one goal at the moments, which, because of the way people listen to the things I say, usually means shutting up. What I say takes on inordinate weight, which is sad for me. I would like to be just one of the guys and just do what everyone else does. So I have to be real careful.

I’m no longer interested in the technical practices of XP, the practices around delivering high-quality, high-productivity, high-flexibility, predictable software. There will be a lot of work around making that happen; cranking it up the next factor of two, but it’s not something I care about. What I care about is extending XP in scope in a couple of different ways. One is in specialties—user interface design, graphics design, traditional business consulting. Because there has been no change in the way business consulting is practiced, there is an opportunity to really turn that on its head.

Jim: Do you think the objective of Agile approaches like XP is to get orders-of-magnitude better results?

Kent: Absolutely on a bunch of different dimensions. I don’t want this [XP] just laying someplace different on the curve. We’re trying to increase business value by an order of magnitude. While this may include dramatically lower defects, dramatically higher productivity, dramatically more business feedback, or the ability to change business functionality at just insane rates, in the end, business value can’t be measured by any single simple metric.

Reflections

The idea of social contracts runs deep for Agilists. On the surface, XP seems to be about programming—refactoring, test-first development, coding standards. But listen to Kent, talk to him in a number of situations as I’ve had the opportunity to do over the last couple of years, and you realize that Kent’s most important vision is about changing social contracts, changing the way people treat each other and are treated in organizations. In an email, in which Kent was angry about an article that discussed a “revised” approach to XP, he says, “I was furious that someone would strip out all of the social change and still call it XP. If he wanted to say, ‘XP inspired me to make the following changes,’ fine, but what he did was emasculate his teams.”

References
Published at DZone with permission of Jim Highsmith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: