XP inventor talks about agile programming

Kent Beck touts shorter development cycles and says agile methods can detect unworkable software projects quicker

Recognized as the inventor of XP (Extreme Programming) and a co-author of the Agile Manifesto, Kent Beck has been a prominent advocate of agile programming and its use of shorter release cycles in software development projects. The founder and director of Three Rivers Institute, which offers various programming services, Beck attended the QCon conference in San Francisco this week, where he answered some questions from InfoWorld Editor at Large Paul Krill.

InfoWorld: Could you talk about the Agile Manifesto and XP?

Beck: The fundamental assumption behind XP is that there are certain activities that contribute to software development success. I asked the question -- what happens if we did those as intensely as possible? Hence the name Extreme. And it turns out that if you take some practices like technical collaboration [and] testing and push them harder than they had been pushed up to that time, at least in typical development, that there's all these nice consequences. You get very low defect rates, which means you can release software much more frequently. You get a very low cost to getting projects into an initially deployable state, low cost and short time compared to other styles of development. And if you take this notion of incremental design, continually investing in design seriously, you can continue deploying new functionality at a fairly steady rate for a very long time. That was how XP started, and it turns out that in order to accomplish all those goals, you also have to, as a team and as individuals, learn a bunch of new social skills: integrity, transparency, accountability. [You] get to a certain speed and the next thing, if you want to go [to] the next step faster, what you've got to do is be able to communicate much more clearly and transparently about what's going on.

InfoWorld: You mentioned trends that are driving agile programming: reliability, low cost of change, increased return on investment. Why is the market moving away from the waterfall style to agile? Or is still just a small portion of developers that are doing Agile?

Beck: Well, it is a small portion of developers that are doing agile, but I think it's growing quite quickly. I don't have numbers to back that up, but that's the sense that I get if you look at the growth of conferences and so on. I think what's driving agile development right now is that it's possible to be much more honest, transparent, and accountable if you have short cycles and you decide that that's what you want to accomplish. There's a huge latent market for software development that's just flat-out honest.

InfoWorld: Why so?

Beck: Because it hadn't been that way for a long, long time.

InfoWorld: You mentioned this morning that there's the problem in which you have to make sure your software works. You say that's something that you should be able to take for granted, but that has not been so. Why has that been the case?

Beck: Well I think it's a combination of technical and social factors that leads to all the defects in deployed software. Part of it is the attitude that software is just inherently unreliable, and customers are conditioned to accept that. Developers are conditioned to accept that. Testers are conditioned to accept that. We just decided it was like the weather and there's nothing we could do about it, which isn't a very responsible position because in fact, there's a lot that software developers can do about it. Both technically, [through] test-driven development, automated integration testing, continuous integration, and socially both in terms of personal pride of workmanship and integrity, not wanting to send out software that has defects. And in terms of relationships of teams.

InfoWorld: There have been these studies that you're familiar with that talk about most software projects failing. Is agile really a remedy for that, or is the jury still out?

Beck: Is agile a remedy for failing software projects? I think a lot of software projects should fail, and the problem is you just don't know which ones until you're pretty well into it. So is agile a remedy for it? No. I think software projects are still going to fail because there still [will be] the promising ideas that don't work out in practice. One thing that agile development can give you is to make sure those projects fail faster, sooner, cheaper, so you can get on with the next thing.

InfoWorld: With agile, you're talking here in iterations of several weeks as opposed to six months to a year? How are you defining the iterations as far as the cycles of when software is released?

Beck: The basic cycle in XP, the basic planning cycle is one week long, which is nice, because it fits in with how humans [work]. At the end of every week the software should have more functionality than it had at the beginning of the week.

InfoWorld: How does XP compare to other agile methodologies, such as Scrum?

Beck: The thing I like about XP is completeness. It starts with broad statements about the values that are consistent with good software development. It talks about the principles and it talks about concrete practices to achieve the kind of goals that we were talking about. So I think the distinguishing feature of XP is that it has kind of this comprehensive scope.

InfoWorld: Can you name any prominent software projects that have been done using XP?

Beck: Carfax, for example.

InfoWorld: I've seen the phrase, cowboy coding. What's the difference between agile and cowboy coding?

Beck: Cowboy coding [is something] which I've enjoyed at times in my life, although not the consequences.... In cowboy coding, you go off and you do heroic stuff and you feel good about yourself because you figure there's nobody else in the world that could have possibly pulled out something like this. XP-style development is courageous, it shares that with cowboy coding. You're going to go and do stuff, there's a bias to action in XP. But cowboy coding is completely opaque, and XP is transparent. Cowboy coding is a solitary activity, and XP is a team activity. Not just programmers working together, but customers, managers, testers. So I think there are contrasts.... The superficial similarity that a lot of people latch onto is that you get going and you do stuff. So you're cutting code very early. You're cutting code not because you're afraid of not cutting code. You're cutting code because it's what generates real feedback.

InfoWorld: You're talking about agile?

Beck: About XP, in XP style. But a cowboy coder will do the same thing. You'll get halfway through the problem definition, they'll say -- okay, okay, I got it, I got it. Go off and start typing. Well, it kind of looks like the XP team is doing that, but they're not because the cowboy coder has finished the conversation and the XP team has just started the conversation.

InfoWorld: Has cowboy coding worked ever?

Beck: Sure, in the short run, and it has huge risks and huge costs, huge hidden costs. I have stories, but it can work at times. And it's a whole lot better than gridlock. But those aren't the only two options.

InfoWorld: What about the situation where you have software now being developed by different teams in different parts of the country at different hours of the day? Is that addressable by agile?

Beck: Yes. That's the way that I work most of the time because I live in southern Oregon, and I still program for a living for a big part of my time. So I'm doing geographical development all the time. Time zones are a challenge. The big challenge is maintaining personal relationships when you're not seeing people. That's what's really hard about it. If you do that, if you have good relationships with people, then you can work out the technical [details] -- who does refactoring when and who's going to check in which code and that stuff  all works out. But it's the relationships that are hard.

InfoWorld: What about Java versus .Net? Does that factor into agile and XP at all, or does it really not matter?

Beck: The more the technology platform lets you make changes at a low cost for a longer time, the better suited it is for agile development.

InfoWorld: So how does that fit in with say Java versus .Net, or does it not really matter?

Beck: I don't think either platform was built with sustainable ease of change as a primary design criteria. That's the sense that I have.

InfoWorld: Is that something that's important in agile programming?

Beck: Yes, that's what you need in a technology.... That really helps in a technology platform. My dad was doing most of the technical side of agile development, programming microcontrollers in assembly language. He had automated tests, he did incremental design, he had small frequent releases, and he wrote rock-solid code.

InfoWorld: Can you use agile methodologies with Java and .Net, or is there another language that would be preferred?

Beck: You certainly can do it with Java and .Net.

InfoWorld: What about scripting languages techniques like AJAX (Asynchronous JavaScript and XML), Ruby, and PHP (Hypertext Preprocessor)? Do they fit into the agile paradigm at all?

Beck: Sure. Ruby, for example, comes from this tradition of human-centric languages. And you could write Ruby in a style that's very maintainable, that's easy to change for a long time. I worry when you get to the database, [I think] that change suddenly becomes harder.

InfoWorld: With Ruby?

Beck: With relational databases in general. But the agile community is coming up with techniques to deal with that.  And the vendors are catching on that that's a differentiator, to have databases that accept incremental change.

InfoWorld: What about Web development? Is that particularly tuned for agile development, or is it just another application area?

Beck: One of the great things about Web development is that deployment is cheap. And if you're doing deployments all the time, it's great to be able to just push to a handful of servers and you're done. As opposed to the embattled days of having to burn CDs and send them out. That's hugely expensive to do deployments. But if you can just push a button, write disk images to your server farm, and you're finished, then you have daily deployments or multiple times of day, even, deployments are technically feasible, although you have to work pretty hard to get the reliability of the software to where you can do that. But it's feasible.

InfoWorld: Was there anything else you wanted to bring up?

Beck: Well, I completely dodged your question about the Agile Manifesto, and I didn't mean to, but I'm also not quite sure what to say about it.

InfoWorld: I guess there were 17 people that signed onto that?

Beck: Right. My name was the first alphabetically, so that's why it's Beck, et al.

InfoWorld: What was your involvement in that?

Beck: Well I was in the room and part of the discussions.... We were trying to find common ground.... We share some characteristics, but there's also very significant differences between the original signers. And what I see happening with that word "agile" is it's just getting washed out. Under the glare of exposure, it's fading. It doesn't mean as much now as it did before.

InfoWorld: So what does it mean?

Beck: I saw a quote from Microsoft today about how they wanted to become a more agile organization. At that point, what does it mean to be agile? I mean, my definition is that you accept input from reality and you respond to it.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies