At the recent Software Development 2000 conference in San Jose, I attended a presentation on XP (eXtreme Programming) given by Ron Jeffries. I had a few reservations going into the class. In my more cynical moments, I imagine someone is out there inventing new trends like this just so they can sell more books, or launch new magazines or trade shows. After sitting through the class, I concluded this was not the case with XP, although I still find the choice of the term "extreme" unfortunate. In my mind it has a certain machismo, daredevil ring to it, hence it sends the wrong message. If anything, XP is against machismo, death marches, programmer heroics, that sort of thing. The more I listened to Jeffries' presentation, the more humane XP started to sound. But you sure wouldn't know it from its name.
What is XP? I probably can't do it justice here, but I'll attempt a brief characterization. (To get the full story on XP, visit the XP website, www.xprogramming.com, or see Kent Beck's book, Extreme Programming Explained.) XP is like iterative development taken to — well, extreme. Iterations occur on a near-daily basis. Some functional piece of code, however small, is to be shipped to the customer just weeks after the project's inception, with more pieces at intervals of two to three weeks. Gone is the lengthy Requirements phase that drives programmers nuts, and results in a spec nobody believes. The emphasis instead is on shipping on a regular basis, with the expectation that this will cause requirements to evolve. As requirements evolve, the code is quickly revised. This is made possible through the use of tightly integrated test suites that tell whether the revision process broke anything. Meeting these mini-milestones helps build confidence in the project, which a programming team so desperately needs.
XP aims not only to make customers happy, but to make programmers happy as well. The idea is that if a team keeps meeting concrete goals throughout the life of the project it won't have to scramble near the end. Programmers get to go home at night, play with their kids, have real lives. (To quote Jeffries, "When you work a 60-hour week, you just work stupid.") XP embraces a few other ideas I find appealing: simplicity; direct and continual involvement of the customer; and testing, testing, testing. None of these ideas are particularly new, but XP bundles them into a coherent whole.
Despite its many charms, I don't see XP as the ultimate software development methodology. I am not sure it is even appropriate for most organizations. I have two main concerns about XP. First, with its emphasis on short-term results and minimal specification, XP seems likely to produce code that lacks overall structure. Such code may turn out, in the long run, to be brittle and hard to maintain. I suggest we check back in three to five years to find out how gracefully it ages. Second, I fear that XP may go the way of TQM (Total Quality Management), a management paradigm that largely flopped in the United States. I believe one reason TQM flopped was because it came with fine print, which XP seems to share: use of this paradigm may require sweeping cultural changes in your organization. In these days of mergers and IPOs, what executives stick around long enough to make any positive change in their companies?
What I do like about XP is its imperative to keep development on a human scale. XP promotes the somewhat radical idea that whatever a reasonably competent programmer can do in a 40-hour week ought to be enough. If it isn't enough, something's wrong with the process, not the programmer. That is a message our industry needs to hear loud and clear. If XP's current popularity can get this much across, it will have done a good thing.
Marc Briand
Editor-in-Chief