On the DSDM mailing list, one of the participants wrote:

> My chief hesitation around XP is that is seems to give a low
> priority to architecture, so that you may end up with a
> zero-bug product quickly, but the product may not meet medium-
> to long-term requirements for performance, scalability,
> reliability, maintainability, etc. because it focusses on
> meeting short-term functionality.

After having practiced XP for nearly seven years now, I would say that, unfortunately, it's a misconception that XP "gives a low priority to architecture."

XP has two planning horizons—the shorter-term iteration horizon, and the longer-term release horizon. The iteration horizon is typically one or two weeks. The release horizon is business context dependent, but is typically one to three months. It's not uncommon for a team to look even further out than a release horizon to understand longer-term product goals, even if they constrain their detailed planning activities to a smaller horizon. XP does not mandate the elimination of common sense.

Within each horizon, the team plans for a number of things, but not just task planning—also architectural planning. It would not be possible for a team to create a good release plan unless they had developed a strategy for how they were building the system, which includes architecture. This strategy is at a level that the team feels is necessary to create their plan, which is often at a lower level of refinement than most architects are accustomed to from processes that practice more up-front architecture. I don't see this as incompatible with DSDM's iteration approach, although XP typically wouldn't have a specific Functional Model Iteration.

As more and more features are implemented, the architecture evolves to support the new feature set. XP prefers the architecture and design to be the minimal, but sufficient one to support the current feature set, but not more. This can be uncomfortable to architects accustomed to larger up-front architectural design. But the intent is to minimize the investment required to produce a deliverable feature set (i.e. maximize ROI and minimize time-to-ROI).

What balances the lesser level of up-front refinement and the effects of evolving the architecture is a continuous retrospection on the state of the architecture, and a disciplined approach to refactoring the system to continuously move the architecture to a state of "goodness." That goodness includes all the necessary "-ilities" that the poster mentioned. XP doesn't let even a partial system perform poorly, or scale poorly, or lack needed maintenance documentation, etc.

This is not an easy thing to do, requiring the developers to be able to frequently take that step back from the code they are writing in support of the short-term feature implementation to see the bigger architectural picture. It's sometimes easy to get stuck in a local maxima of design and not see a larger improvement that can be made. IMHO, not all developers have nurtured this skill set. But it's similar with up-front architectural activities—they are not easy either and require a skill set that not all developers have nurtured.

So I would argue that XP, in fact, places a continuous emphasis and priority on architecture. XP places a very high value on the quality of the architecture, design and code, and mandates the refactoring practice to ensure the team always retrospects on that quality and moves the system back to an acceptable level of goodness when it strays. Normally this is done in a series small refactoring steps, but it is sometimes necessary to do a larger refactoring step to break out of a local design maxima.

It's unfortunate that this misconception is prevalent, but perhaps not surprising. Most of the refactoring writings focus on smaller-scale refactorings that are intended to improve code quality or local design quality. It's only recently, through books like Joshua Kerievsky's "Refactoring to Patterns," that larger-scale refactoring is being publicized. But XP gurus like Ron Jeffries have been discussing this for years on the XP mailing list, so it's not a new concept and has been part of mainstream XP practice for some time. I've also seen teams try XP without proper refactoring, essentially using XP as a project management wrapper for a "code-like-hell" development process, but that's not what XP is about.