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.
Have you had experience using the XP approach to building software? If so, what are the pros and cons from your perspective?
XP offers several compelling features:
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.
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.
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.
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.
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.
XP Meets XML [XML.com]
Return to the Linux DevCenter.
Copyright © 2009 O'Reilly Media, Inc.