A lot of people seem to think that XP's "embrace change" precept is synonymous with "design your code to anticipate change" -- or at least believe that they satisfy this precept with a general up-front design that (they believe) accounts for likely future additions. This is of course, very different than how XP'rs actually recommend one embrace change: by keeping the code in a state where the current requirements are satisfied with as simple a design as possible, rather than by guessing at future design needs that are beyond the scope of the features currently known.

That sound you just heard was Anti-XP pundits 'round the world giving off a simultaneous "Harrumph!!" -- as if our insidious, evil goal is to replace professional high-quality development, with hack-n-slash cowboy coding. However nothing could be further from the truth. The disparity stems from confusing simplistic with simple, and from seeing "anticipating change" as synonymous with "flexibility." The actual idea is to build code that handles our current needs clearly, with no speculation, no stubbed functionality, no currently uneeded generality, and most importantly: No Duplication.

Martin Fowler describes the problem very well:

In other words: by trying to make code easy to change, we make it harder to change. So instead, let's make code simple, clear and well-factored, allowing change to be as localized as possible.

That way, regardless of what changes we may face, the impact of those changes will more closely reflect the size of the feature we are adding rather than being a function of how much code has already been written -- if we remember that speculation does not equal reality, hacking does not equal simplicity, that readiness for change, does not equal readiness for a change, and that complexity is the true enemy of flexibility.