Embracing change == confronting reality

XP encourages us to "embrace change". But what is change in the context of a software project? My colleague Darren reckons that the biggest change comes when a project ends: but while that is a significant change, I think that there's a more important source of change. Reality.
Reality bites us all the time, because so much of software development is about constructing abstractions in mental models. We have models of code and design, models of the business domain, models of the how user will use the system, and many more. But when our software is actually put to use then the flaws in those models become apparent, and we have to change our software to accommodate reality. For teams that deliver their software early and often, this means that the most regular cause of change is going to be reality.
In XP this kind of change is just another kind of feedback and it is welcomed accordingly. More generally, the agile manifesto encourages agile software teams to confront reality through the values of working software and customer collaboration.
But un-agile project teams only need to confront reality in the implementation and maintenance phases. Which is perhaps why the maintenance of those projects costs so much: the software was not written to accomodate reality. As my colleague Joe points out, if you wanted to write maintainable software then the things you would do are very close to what the best XP teams are already doing.
So, are you keeping it real...?