If you follow the latest and greatest in programming methodologies, you must have heard of eXtreme Programming, otherwise known simply as XP. Love it or hate it, this approach to software development has been with us for ten years now, managing to outlast more than one return of bellbottom pants to the fashion scene. For those who are looking to improve their development team's ability to put out solid, tested code but don't have the budget for a full Quality Assurance (QA) testing regimen, XP can be a tempting path to follow.

However, XP isn't for every team or every project, even though some managers are determined to stick religiously to this approach. Here's how to determine whether XP is the right choice for your needs, rather than becoming a slave or victim of fads.

Team Size

According to the proponents of eXtreme Programming, certain factors make some projects better suited to this methodology than others. The first major issue is the size of your programming team. In general, XP is most effective in cases where small teams are involved—typically two to twelve programmers. Small teams are more flexible, and better able to adapt to change than fifty- or one-hundred-person programming behemoths.

Note, though, that the recommended number of people does not begin with one. You need an even number of programmers due to the XP concept of Pair Programming. To use this approach, you literally pair up your team, with each pair sharing a single computer and each half of the pair focusing on a different angle of the problem. While one person types and actually implements the code, the other developer watches for syntax and spelling errors, as well as keeping in mind where this current piece fits into the whole work. These two people switch back and forth as needed, and brainstorm together on the best ways to approach a particular dilemma.

As you might guess, programming in pairs takes a bit of practice. Of all of the XP techniques, this is perhaps the one technique that people are most likely to consider not following when integrating XP into their development program. Some programmers simply find this approach too frustrating, especially when the pair is not properly matched according to both personalities and complimentary skills. In other cases, management has been known to eventually lose sight of the original goal and split the pairs apart, in order to throw more people at a project (to speed it up or start something else).

Customer Involvement

Commitment to XP has to run throughout the organization, from the top echelon of executives all the way down to the programmers in the trenches, and even into your customer base.

To make best use of eXtreme Programming, at least a small portion of your customer base must be interested in and capable of being involved in developing and testing your application. Assigning one or more customers to the actual development team is recommended, along with insisting that the representatives sent by the customers be experts that will use the application, since only they have a deep enough insight into what it is that the product needs to be able to accomplish for them.

Once you have access to these user experts, you have them write up one to three sentence basic descriptions—called user stories—of the functionality they require. The Stories that are too complex to implement within three weeks have to be broken into pieces that can be handled in one to three weeks; as a result, your developers may require access to the user experts again to ensure that the new, smaller Stories are correct.

Later, once the team selects which of these Stories will be implemented in the program's next release, the customers select what features (Stories) will be worked on first. They then also help to design acceptance tests, which are batteries of automated tasks the program can be put through to ensure that it is doing what it is supposed to be doing. Customers are, at points, able to see the test scores and check things for themselves, to make sure that the tests evaluate things in a proper manner. You'll also need customer input if your project timeline starts to slip, and it's time to develop a new one.

So, customer buy-in definitely has to be solid. If none of your customer base are interested in participating, then no level of management dedication will be able to put eXtreme Programming to serious use.

Project Parameters

XP is best used on projects where the parameters are not stable; that is, where the requirements constantly change. Frustrated by customers who just don't know what they need or want? Do you need to roll out a new version of your program every few months? These are the scenarios where XP shines. eXtreme Programming is not as good a choice for those who have a nice flat set of needs.

Another scenario where XP is a recommended methodology when your team finds itself treading into unfamiliar territory. Focusing in on exactly what your customers need to do ensures that the resulting product will be useful, mitigating the danger that what seems like a good idea on paper turns out to be a disappointing waste of time, once it's released into industry.

Wrapping Up

eXtreme Programming is just one of a number of lightweight software methodologies that have appeared throughout the last decade or so. If you find that XP is not right for your organization, but do feel that a change in how your programmers work would help to produce better code, then consider instead Agile methods. XP and Agile development are fairly closely linked. However, if you do find that your particular project meets the requirements that make it suited for XP, hold onto your hat and get ready for a fun ride. When at all possible, try to pull in a few people who are experienced with Pair Programming to help everyone get a feel for how it works.

The important thing is to choose the right tools for the job. Many programmers have found themselves working in companies where management is so obsessed with the XP way that eXtreme Programming is the answer to all problems; expressing any hesitation over this approach can actually mean losing one's job. Such an atmosphere is not conducive to employee satisfaction, even when you aren't trying to turn how everyone works upside down. Change is a threatening thing. Present your reasons in a constructive manner, be willing to listen to people's concerns, and expect the first project to take longer than anticipated as people get used to working in this manner.

If you're lucky, your developers will react as a student at North Carolina State University did when finishing a Pair Programming assignment and returning to programming on his own: “Without my partner, I feel like I lost half my brain.”