Actually, I think you're putting your finger on a certain tension here (I won't say contradiction) in the agile principles. On the one hand, develop incrementally and adapt to change; on the other hand, build the simplest thing that meets the requirements now (and resist the temptation to avoid generalizing up front). The trouble is that code that does X in a direct, concrete way can't always be easily changed to meet the new requirements when X changes to X'.
The typical agile answer is, "We'll just refactor to allow the necessary changes as we go along." This is an oversimplification, because the cost of such refactoring isn't always low. Sometimes it's no less than the cost of rewriting the system. Other times the refactoring leads to suboptimal solutions for X', compared with what you would have if you designed for X' originally. I've seen agile projects get into trouble this way.
There's no question that up-front generality is often misplaced (since you can't know for sure what you'll need in the future) and can cause a lot of complexity damage. But the answer doesn't lie in making a "process" out of a half-dozen or dozen principles and pretending you've solved the problem.
Oh, I understand. My current job is an agile shop and I've seen firsthand how dealing with poorly thought out legacy design can be a pain. We take a lot of pains these days to make sure decisions today don't get in the way of plans tomorrow.
Personally, I'm not a huge fan of agile but it does hit on a few things right.
The typical agile answer is, "We'll just refactor to allow the necessary changes as we go along." This is an oversimplification, because the cost of such refactoring isn't always low. Sometimes it's no less than the cost of rewriting the system. Other times the refactoring leads to suboptimal solutions for X', compared with what you would have if you designed for X' originally. I've seen agile projects get into trouble this way.
There's no question that up-front generality is often misplaced (since you can't know for sure what you'll need in the future) and can cause a lot of complexity damage. But the answer doesn't lie in making a "process" out of a half-dozen or dozen principles and pretending you've solved the problem.