Abstraction should not be a response to imagined future requirements (though there is a fuzzy boundary between imagined and reasonably-foreseen near-future requirements: you don't want to spend effort solving problems from the hazy future, but you also don't want to be doing major rework in a month because you didn't take reasonable steps in anticipation of something clearly anticipated but not fully solidified), but code duplication isn't the only trigger. Problem decomposition often results in reusable abstraction as a natural consequence.