Some of the reactions to my post on changes being expensive hinted and some explicitly said that Agile Development and Test Driven Development can make changes cheaper. I think they can help you to make the changes easier, but they can neither reduce impact nor cost of the change. Let me elaborate.
The reason we needed Agile development because we were otherwise forcing ourselves to define all the requirements, even if we did not know them. Agile development helps us to work with the requirements we know and discover more as we go along with the help of short iterations. What this does is that it explicitly acknowledges that new requirements during development are inevitable and that software development has to be agile enough to be accomodate them. It is more about us, the people and the process, than the software itself. If a requirement changes, especially a core requirement, in later iterations, it is still expensive.
Even with the Test Driven Development, it is not about the software at all. It is about our process of development where we first write the tests and then the code. However, if there is a change in the existing behavior, the impact and cost of the change will not reduce.
We also have best practices like MVC which helps us separate the concerns. When there is a change requested, we know where the change will have to be done. We have other design and architectural patterns using which we can componentize the system and try to localize changes. But this will not be always true. Changes will still have their impact, and the tests will still have to be run. If it is a change that affects the entire system, you will have to carry the system and integration testing, there is no escape from that.
And some cost of the changes will not be affected by the software development at all. A GUI change in the new version of a product can make the user learn new things. This is an impact of the change, and this is not cheap. And similarly there will be changes, which can be completely localized and encapsulated from others. However, none of them can reduce cost of a change, it would be as it is.
For records sake, I do not intend to say that software development should not consider the changes. I actively follow Agile development in my software development process. However, the team has to know what entails in changing something. It is not about avoiding the changes, but about knowing what is involved in the change. I have seen many software professionals measure a change in terms of lines of code, which I think is an utter failure. Severity of the change will always be defined from the impact it will have in the system. And this is the reason we want good architecture, good design and good code so that we do not have spend time in finding that out, which can only make changes more expensive.