An Introduction to Extreme Programming

Extreme Programming (XP) improves the efficiency of writing software. This is accomplished by streamlining complexity, delivering top business value early and consistently, and reducing the cost of nearly inevitable changes to the business rules, programming environment, or software design. Many of these practices have been part of conventional wisdom for years, but rethinking their interaction is the value of XP.

In its purest form, Extreme Programming is simple. The central tenet is, "Find the essential elements of creating good software, do them all of the time, and discard everything else." Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance.

XP offers several compelling features:

• Comprehensive unit tests,
• Short release cycles,
• Adding only what's needed for the current task,
• Collective code ownership,
• Continual improvement, and
• Adding features in the order of importance.

Basic XP approach

Here's how a typical Extreme Programming scenario might look from the programmer's point of view. This is a very generic procedure outlined here, but it will give you some idea of the work flow if you're a developer in an XP environment.

• Customer lists the features that the software must provide.
• Programmers break the features into stand-alone tasks and estimate the work needed to complete each task.
• Customer chooses the most important tasks that can be completed by the next release.
• Programmers choose tasks, and work in pairs.
• Programmers write unit tests.
• Programmers add features to pass unit tests.
• Programmers fix features/tests as necessary, until all tests pass.
• Programmers integrate code.
• Programmers produce a released version.
• Customer runs acceptance tests.
• Version goes into production.
• Programmers update their estimates based on the amount of work they've done in release cycle.

A contrast of styles between XP and "traditional" programming

Most experienced programmers are familiar with the "large scale up front" design approach. XP programming doesn't embrace this approach for a couple reasons.

A large up-front design means that the whole programming team sits down and plans out the entire program before writing code. That would work if two things were true. First, the team would have to know exactly which features were to be implemented. Second, the team would have to be able to anticipate all issues that would come up when actually writing code.

There aren't a lot of domains where that's possible. (NASA comes to mind.) Customers change their minds or explain things differently, or someone comes up with a better way to code something, and the grand design is different. If it changes more than a little bit, someone will have to update it, and a little more time spent on the initial design was wasted.

The same goes for coding things you don't yet need. If the project has enough uncertainty that things could change, plan on them changing. Don't spend time on features and designs that might be thrown away next week or next month, and that no one will use for next month.

Instead, XP embraces the notion that you should spend your time on the features that provide the most business value to the customer. If you have good unit tests and a simple design, and if you've been working with other programmers, then adding features when you need them isn't nearly as expensive as you would think.

We've seen some of these principles applied to high-quality open source projects. Freed from traditional constraints like market pressure and ever-changing business demands, coders can explore various approaches, picking the best available solution. With the short feedback loop between developers and users, and a culture that encourages savvy users to add features and fix bugs, a project can evolve in new directions very quickly.

Not everyone thinks XP is the best approach

Software produced this way also has its detractors. Commercial developers see it as a competitive threat. Users burned by low-quality freeware and shareware see it as a toy. Experienced managers look at the morass of e-mail folders, IRC logs, and CVS commits, wondering how anything ever gets done.

But when you get right down to it, XP goes against conventional wisdom. Detractors look at XP and often say, "It will cost more to change things in the future, so we'd better add everything we might need right now."

Others look at pair programming and say, "I'm a good programmer. I don't want someone looking over my shoulder and slowing me down, and I don't need somebody pointing out bugs."

And skeptics often embrace the attitude, "Programmers can't be trusted to make good estimates, and managers can't be trusted to take programmers seriously. Customers can't be trusted to know what they want."

Conventional wisdom is based on experience, and therefore has some merit. Where it misses the point is in its failure to grasp the concept that XP practices actually reinforce the traditional process, not degrade it.

The open source connection

Open source development has similar advantages to Extreme Programming, though the motivations may be different. Consider phrases like "scratching his own itch," "release early and often," and "patches welcome." Distributed development, open for the world to see, allows potential customers and contributors to evaluate the evolution of a project at any point. In some cases, given the right motivation, they can even redirect development focus.

These two methodologies overlap in some areas and lock horns in others. Where XP promotes two programmers working together at one computer as a way to reduce bugs, write clearer code, and create better designs, open source collaborators may rarely meet in person, if ever! On the other hand, both approaches often have short release cycles, adding a few features and rapidly integrating user feedback.

Can the XP and open source worlds merge?

Is it possible to merge open source and XP methodology? Nothing in XP prevents source code from being given away freely. Nothing in open source development precludes a feature-at-a-time development style. In many ways, they complement each other -- user-driven focus, continual code review, short release cycle, and tight feedback loops. There's more in common than one might expect at first glance.

From the outside, both methods look like pure chaos. Somehow, though, order emerges, and programmers produce good code that meets requirements and meets or beats the schedule and the budget. At least, when applied properly. The secret is knowing when, where, and how much.

chromatic manages Onyx Neon Press, an independent publisher.

Essential Reading How to Keep Your Boss from Sinking Your Project By Andrew Stellman, Jennifer Greene Like it or not, your project needs management. Yet few good software projects can survive bad management. If you're a programmer on a high-visibility project, this PDF offers five principle guidelines for managing upward that will help you help your boss make the right decisions about setting project expectations, working with users and stakeholders, putting the project on the right track and keeping it there. The PDF also covers what problems cause projects to fail and how to fix them, and what you can do to keep your software project from running into trouble. Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.