Resources • Click here for more resources

Develop on the Edge With Extreme Programming
Extreme Programming (XP) is paving a new way for how developers approach their projects.
by Brian Noyes

Unless you've been living under a rock in the software development world for the last couple years, you at least have heard of Extreme Programming (XP). You might not be quite sure what it's all about or why you might want to consider using it, but these days you can't get into software methodology discussions without knowing a little about XP because at some point most methodologies end up comparing themselves to it.

As the name implies, XP lives on the far end of the lightweight software processes scale. It takes common practices and principles of software development and pushes them to the extreme to achieve the most productive and cost-effective software process possible. Some of XP's practices, such as emphasizing testing and communications, are simply common sense shared by other methodologies. Others, if taken in isolation, are considered somewhat radical and could be harmful to your efforts if you don't combine them appropriately with other parts of XP. But through the synergistic effects of individual XP practices, combined with the right kind of customer, team, and a touch of courage, you can achieve some impressive productivity using XP and satisfy your customer's requirements better and faster—and your programmers are likely to enjoy their work a whole lot more, as well.

XP is centered around the premise that anticipating and understanding every system requirement ahead of time is impossible, or at least extremely difficult. If you try and fail, you either waste money and effort building the wrong component, or worse yet, you build something that can't adapt to a software project's inevitable changes. Customers are fickle and often don't know what they want until you put a product in front of them, and their own desires, schedules, and funding are likely to change frequently over the lifecycle of a software product.

Figure 1. Control Your Costs

Traditional processes assume the cost of change over the project's lifecycle grows exponentially as time goes on, and if you don't spend time addressing things up front, changing them later will be too costly (see Figure 1). Consequently, traditional approaches have you spending a lot of time in requirements analysis and design, attempting to capture everything up front in documentation, which forms the blueprint for the subsequent software "construction" process. But XP assumes that you can flatten the cost of change curve by applying communications, testing, and flexible processes intelligently to minimize the effort required up front anticipating what you might need later. It focuses on how to build quality applications quickly that address the most important current customer requirements, and it lets you add features later when needed.