Kent Beck is one of the three creators of the agile process extreme programming (XP), and author of JUnit. Builder magazine caught up with Beck to talk agile methods and his future plans with software company Agitar.

Why did you decide to start XP? What was wrong with the many methodologies that were around at the time?
I had picked up a bag of tricks that worked for me. When I was asked to coach teams, these were the tricks I turned to. With teams, I took the opportunity to push them further than I had before and the combination worked better than I expected.

In what circumstances is XP not the right choice for a team of developers?
I don’t think it is a question of right and wrong. The most natural fit of XP, the least resistance, comes when XP’s values are closely aligned with the organisation’s values. Organisations that value secrecy, complexity, isolation, passivity, and hierarchy have a lot of trouble with XP. No organisation would say they value secrecy, complexity, isolation, passivity, and hierarchy, but by looking at their actions many organisations do hold these values. In such a company, XP requires high-level support, patience, persistence, and iron will.

Can XP work with the solo developer?
Certainly. It’s easy to sit together when there is only one of you. All the XP practices that aren’t explicitly about social interaction can be applied by a solo developer.

What are your thoughts on Model Driven Development? Can MDD and XP be used together?
MDD is programming. Whether the language is graphical or textual and whether the language is high level or low level, the same psychological and sociological factors affect software development.

Is Model Driven Development something you endorse?
I’m all for better programming languages. Whenever a new language comes out, though, I’m concerned with the maturity of tools available for itââ,¬”testing tools, especially those that can be used test-first; speed of turnaround from making a change to validating that it worked; automated refactoring; team tools; integration with other tools. The value of a programming language is a combination of the design of the language, the tools and libraries available for it, and the maturity of the culture around it. I continue to evaluate MDD (and other languages) along all of these dimensions.

What are your thoughts on methodologies used by many open source projectsââ,¬”developing software over the Web?
I find it interesting that starting from a totally opposite first principle–programming is an economic activity versus programming is a leisure activity–open source and XP come to very similar conclusions about what practices to use. I think this points to a congruence of values. At least some of the XP values listed in the recently-published second edition of Extreme Programming Explainedââ,¬”communication, simplicity, feedback, courage, and respectââ,¬”could be used to characterise many open source projects.

Is writing open source software really a leisure activity though?

Yes, because in general you don’t get a fair trade of value for your work. I did some envelope calculations of the economic benefit generated by JUnit, its cousins in other languages, and the developer testing revolution it spawned. Conservatively, it is hundreds of millions or billions of dollars a year. My total economic take from this process is less than .001% of that.

JUnit cost more to produce than I have received for producing it. When I pay to participate in an activity I classify that as a leisure activity.

Commercial software development begins with the assumption that programming is an economic transaction. Open source begins with the assumption that economic payback, if any, will come as an indirect result of programming. Naïvely, I would have assumed that given these opposed first principles, very different styles of development would be appropriate. Instead, open source and the best of commercial programming (whether based on Extreme Programming or some other highly effective style of development) are very similar.

Two examples of the similarity are frequency of integration and developer testing. Both open source and XP projects integrate and test their code two to four orders of magnitude more frequently than was common ten years ago. A four order of magnitude change is enormous. A quantitative change of the magnitude results in several qualitative changes. Open source and XP projects both grew to integrate, build, and test with similar frequency. Ten years ago respectable developers didn’t write automated tests. Now, writing tests in close conjunction with programming is au courant.

In Australia there has been a lot of discussion around the compulsory certification of IT professionals, including software developers. What do you think of certification, and do you think it can aid in developing quality software?
Psychology researchers once gave an IQ test to a gorilla. The gorilla naturally scored very low. However, when they looked at the questions they discovered that the conventional answers didn’t make sense for the gorilla.

The gorilla connected -bed” and -tree” for instance, instead of the -correct” answer which connected -bed” and -house”. I’m afraid a certification test would have questions like, -True or false. All requirements should be gathered and specified before development commences.”

I won’t say who plays the part of the gorilla and who the human in this scenario, but I do know that a wise, practiced XP-style developer would give the opposite answer from a wise, practiced waterfall-style developer.

Many readers might not know you joined Agitar software last year. Why did you decide to work with Agitar in particular and what do you do day-to-day?
The biggest trend in software development is towards greater visibility and accountability. Agitar’s products improve the ability of the whole team (customers and managers included) to -feel” the quality of a product throughout software development while at the same time reducing the cost and improving the effectiveness of that visibility for programmers. Also, I have been looking for a way to commercialise JUnit and Agitar gave me a chance to share in the success of a commercial venture while at the same time being able to continue development of JUnit. My position with Agitar is part-time. The rest of my time I spend programming, consulting, writing, hosting workshops here in southern Oregon, and public speaking.

Besides your own books, what is your favourite programming, architecture, methodology, or IT book?
The Timeless Way of Building by Christopher Alexander. It’s all in there: incremental development, aesthetics, the empowerment of users, focus, intensity. If you insist on a programming book, I’ll pick the K&R C book, which is a model of clarity, usefulness, and at the same time a subtle and powerful cultural manifesto.

Outside Agitar, what projects are currently keeping you busy, or are you enjoying?
Erich Gamma and I are working on a new JUnit release that will mark its first significant architectural changes since JUnit was very young. I have also started programming little games for fun recently, which reminds me how much I enjoy the act of programming. This has evolved into four-day Programming Intensives which I host quarterly at my office here in southern Oregon (http://www.threeriversinstitute.org). I have also been enjoying transporting my son to racquetball tournaments.