One of things that come with experience is the ability to foresee the potential changes and ensure that, when possible (preferably during the initial spec phase) the solution is extensible/flexible enough to accommodate the most likely changes.
For a simple example, if you're asked to implement something like a blog, you would naturally be prepared to be asked for authentication, authorization, contact us forms, commenting, etc. If you're aware that there's a high probability of such a change request in the early phases (but not NOW), then that anticipation will usually result in better code.
That's exactly what I think does not work.
You can't see the future. Of course a simple project want to have that, but a big project is unpredictable. You should make it flexible by having a great test infrastructure to move forward fast, but you should try to create something that doesn't exist yet. Maybe it is needed, maybe not, it's just too unpredictable to write code for something that doesn't exist in the customers head.
I didn't mean "implement features before they're requested". What I meant was that designing flexibly will allow you to iterate better, and given some experience, you will probably be able to "predict" the next feature req or 2.
For a simple example, if you're asked to implement something like a blog, you would naturally be prepared to be asked for authentication, authorization, contact us forms, commenting, etc. If you're aware that there's a high probability of such a change request in the early phases (but not NOW), then that anticipation will usually result in better code.