I read a recent Builder.com article, “Eight reasons why extreme programming won’t work in your shop,” as well as the heated discussion that followed. One thing that struck me about the article is that the flaws in extreme programming (XP) might not be in the methodology so much as in its misapplication. I’d like to offer examples from my past development experience to illustrate this point.

The role of the on-site customer
The on-site customer is one of XP’s best contributions to IT development philosophy. With a rapidly changing business process wreaking havoc on traditional development efforts, XP offers a development methodology to accommodate this faster pace. Object-oriented programming addresses this from a technical standpoint, but the ongoing presence of a user with the appropriate domain knowledge is just as important.

In one of my XP projects, I traded places with the customer representative and set up shop at the customer site for weeks, immersing myself in the user domain. Between us, we transferred every bit of useful knowledge we could to the development team. We found shortcuts in the interface that would never have occurred to us otherwise, and well in advance of testing, too. Expensive? Perhaps. But it facilitated the speed and quality we were shooting for.

Documentation wars
In the XP debate, one argument is that the customer rep’s presence lessens the demand for proper documentation. I’d argue that the rep’s presence should enable the opposite: The customer can help with the regular production and revision of written requirements, commentary, and the review of work in progress, as well as the ongoing editing of your team’s documentation to synchronize results with the customer’s efforts.

The XP environment is one of sustained design evolution, as different from the traditional design-it-then-program-it paradigm as it can be. However, the fact that XP isn’t about writing a cookbook and then cooking the meal doesn’t diminish the need for thorough documentation. On the contrary, my experience was that documentation saved the project’s scope and schedule more than once. Our continuous design changes would have been hopelessly inefficient without the perpetual backtracking and review we were able to do by carefully recording each step. And our ability to organize the many different voices contributing to the design effort came from our diligent practices.

Pair programming: Creating odd couples
Pair programming should produce short- and long-term results. With it you can achieve rapid code generation with redundant expertise and an error filter in the coding phase and enable the cross-pollination of skills that your group needs for the long haul.

Always pair an experienced programmer with a less-experienced programmer. Never pair two team members of equal ability and experience.

The second time I worked on an XP-style project, we went all out in creating programming teams. We created the oddest matches possible in search of synergy and cross training. The standout mix was the pairing of our most experienced programmer, one of those down-to-bare-metal, assembler-spouting geeks from the old days, with a kid who was up on all the latest design tools and relational database technology. They didn’t particularly like each other. In fact, they couldn’t stand each other. But inspiration took over, and between them, they generated a new rapid-access query method for grabbing and transferring large batches of data that made the product more efficient on a network.

The dangers and virtues of refactoring
It’s rightly said that refactoring is a questionable substitute for front-end object modeling, and perhaps I’m parochial enough to be stubborn on this point. For now, anyway, I view refactoring as a useful tool for safeguarding the pair programming process. To see it as a rapid design technique on a par with diligent front-end object modeling doesn’t make sense to me. I’d suggest a synthesis, with careful front-end design analysis that anticipates significant change and refactoring as a follow-on tool.

I’ve never launched a development project without rigorous front-end modeling, and I’d have reservations about initiating programming otherwise. It’s one thing to choose a dish you’re going to cook and then modify the recipe as you go but another to fire up the stove before you’ve even listed any ingredients.

The point of refactoring is not to give a green light to an anything-goes design process that consists entirely of programming. Refactoring is about intentionally checking your coding process at key points in development to ensure that the overall design, tentative though it may be, continues to conform to the user’s intended process. Object modeling at the onset of your project need not constrain this check-and-balance system; these two processes need not be an either/or proposition. They can work together.

Mutual accountability and the optional scope contract
Objections to the optional scope contract in the rapid development scenario seem contrived. I don’t buy the idea that it lessens programmers’ accountability. The need for such an arrangement is obvious, since the justification for XP is rapid development and deployment in a dynamic environment. Project scope and requirements are expected to change, perhaps drastically. The optional scope contract is a necessary safeguard for both parties.

My team achieved this easily with a contract provision that married optional scope changes to the on-site customer rep. The terms of extended work and modified requirements were tied to the customer rep’s written assessments. This put the responsibility for extensions where it belonged and gave us the checks and balances needed to make certain that the inevitable scope shifts were well focused.

Mutual accountability and sharing authority
The best way to make XP work is also the most counterintuitive. You’re trying to leverage your developmental assets, minimize do-overs, and optimize the fit of the final product, gutting traditional processes along the way. What you must have in order to make it all work is something the formal methodology glosses over: good old-fashioned accountability between your team and your customer. What you expect, and what you’re willing to offer, must be clearly defined between you and the customer and monitored throughout the project. Both must be willing to commit time and energy—minimalist doctrine notwithstanding—to hold one another accountable in solid communication and agreement upon deliverables. Such an old-fashioned, kludgy arrangement may seem contrary to XP’s lean-and-mean goals. Developers often don’t like to chain themselves in this way, but it’s important in the fast-moving XP environment.

Making XP work for you and your customers
Hitting the right mix of best practices from the “old” and “new” worlds of development is XP’s sweet spot. Finding the right mixture is just trial and error.

Are you XP-erienced?

Want to share your extreme programming war stories? Tell us about it or post a comment below.