Book Excerpt: Introduction to Extreme Programming

The tools described elsewhere in this book will help you realise many of the goals of XP, but you do not have to adopt the entire XP methodology to get value out of this feature and chapter. Automated testing, for example, can help you refactor code regardless of whether you are doing pair programming. Continuous integration can help you detect and fix problems early in the lifecycle of the system regardless of whether your customer is on site. However, because this book discusses XP throughout, it is useful to have a short overview of the entire methodology. If you are already familiar with XP, you may want to go directly to Chapter 2, -J2EE Deployment Concepts."

XP Overview
XP is a lightweight methodology that focuses on coding as the main task. With XP, the code-centric activities are in every stage of the software development lifecycle. Some practitioners of more traditional methodologies (most seem to be CASE tool vendors) have criticised XP, claiming that it involves reckless coding and is not a real process.

	This chapter is an excerpt from: Professional Java Tools for Extreme Programming By Richard Hightower, Warner Onstine, Paul Visan, Damon Payne, Joseph D. Gradecki, Kate Rhodes, Robert Watkins, Erik Meade WROX Publishing ISBN: 0-7645-5617-7 768 pages

On the contrary, XP is an extremely disciplined methodology that centers on constant code review; frequent testing; customer involvement and rapid feedback; incessant refactoring and refining the architecture; continuous integration to discover problems early in the development process; ongoing design and redesign; and constant planning. The following sections of this chapter discuss the core values, principles, and practices of XP.

Four Values of XP
Kent Beck, originator of the XP methodology, defined four key values of XP:

• Communication
• Simplicity
• Feedback
• Courage

Communication is facilitated through pair programming, task estimation, iteration planning, and more. The goal of communication is to provide a place where people can freely discuss the project without fear of reprisal.

Simplicity may seem counterintuitive because it is common in our industry to overly complicate our development projects. The aim of a project is not for the alpha developer to show his technical prowess, but to deliver value to the customer. Don't over-design algorithms. Don't create an artificial intelligence system when all you need is a few if statements. Don't use EJB or XSLT just because doing so will look nice on your résumé. Choose the simplest design, technology, algorithms, and techniques that will satisfy the customer's needs for the current iteration of the project.

Feedback is crucial and is obtained through code testing, customers' stories, small iterations/frequent deliveries, pair programming/constant code reviews, and other methods. For example, if you are unitlevel testing all the code you write several times a day, you are constantly getting feedback about the quality and production worthiness of the system. If something is wrong, you will know right away, instead of being unpleasantly surprised the night before product launch.

Courage is all about being brave enough to do what is right. Have you ever worked on a project where people were afraid to throw away code? I have. The code was horrible and convoluted, and it systematically broke every style, rule, and convention. Yet management and quite a few developers were afraid to throw away the code because they weren't sure how discarding it would affect the system. If you follow the tenets of XP, you will not have this problem. Unit regression testing builds an intense sense of courage. When you know the changes you make will not break the system in some unforeseen way, then you have the confidence to refactor and re-architect code. Testing is key to courage.

If, after several iteration of a project, you find a cleaner, less expensive, more performant way of developing a system, you will have the courage to implement it. I have, and it is a blast.