Suffering-oriented programming rejects that you can effectively anticipate needs you don't currently have.
I do anticipate, however, I never do it in code. Rather, I find that just thinking through some scenarios helps me to see where the code might start evolving, and to make sure that that part of the code is isolated enough to change without having to change everything else, if the time ever comes.
(Perhaps Nathan includes this in his "make it beautiful" phase, but I felt it deserved to be made explicit. I've too often heard YAGNI used as an excuse to not even think about a problem, let alone code for it.)
I agree, as some agile guru said, a plan is useless but planning is essential. An important thing along with avoiding making useless features is also to avoid building a design that is hostile against features we do need to add. Building a good design without having any anticipation of what will come is in my point of view impossible. The tricky part is to keep the anticipations and assumptions to a reasonable level.
Good point. Breaking down the code into "isolated enough" units as you write it shouldn't add much complexity or effort. It actually makes testing / debugging and refactoring easier. You cannot anticipate what will need to be added, expanded or improved, but you can be sure something will.
I do anticipate, however, I never do it in code. Rather, I find that just thinking through some scenarios helps me to see where the code might start evolving, and to make sure that that part of the code is isolated enough to change without having to change everything else, if the time ever comes.
(Perhaps Nathan includes this in his "make it beautiful" phase, but I felt it deserved to be made explicit. I've too often heard YAGNI used as an excuse to not even think about a problem, let alone code for it.)