The conventional wisdom is that you should code anticpating future requirements. It is assumed that extra work now will save future work. It is thought to be cheaper to add features during design than it is during testing or maintenance

The extreme programming people disagree. They argue that anticipating features is a waste of time because you will guess wrong most of the time.

If you assume that planning ahead pays off, you are inclined to remember all the times that planning paid. You are less inclined to remember the times the up front costs were not recovered.

The XP way is to code only as much complexity as you need right now. If you can get by with csv files now, don't install Oracle.

This is not to say that you shouldn't save your simple good-enough-for-now programs. When (if) the time comes to put them to new purposes, spend the energy to make them more complex (general)

The XP religion doesn't require the faithful to pile spaghetti on top of spaghetti. "Good enough for now." alone probably won't work well. There are other XP principles (build the test code first, program in pairs, talk to the customers, revise and improve whenever possible, etc) that keep things in balance.