xkcd nails it :-
It’s the classic dilemma, isn’t it.
Faced with coding a new bit of functionality, do you write the version that solves only your immediate problem or do you think ahead and try cater for future, more varied, uses too?
Perhaps you want to find that middle ground; lay it out enough that the opportunity for future generalisation is documented well enough and sufficiently in place so that you can move on in peace, having noted the opportunity and laid the tracks for future development without having expended too much effort.
At least that’s what I generally aim for. (Initially.)
I see it as a professional coder’s challenge. Or just a productive coder’s challenge. To remember to code for the client, or your objective, and to push distractions aside, interesting as they might be. Interesting sidelines can turn into a form of procrastination otherwise.
Put it another way: not on their dime, unless you care confident you can deliver ‘something extra’ that they’ll appreciate without ruffling feathers. It’d be like the cartoon otherwise.
Don’t get me wrong. I love the idea of giving more than was asked for but a reality, for independent developers like me at least, is that you have to be careful of overhead time. By only briefly sketching it these out in documentation, etc., in the main run of things elaboration is pushed to overhead time, where you’re more likely to be critical about implementing it or not.
Other articles on Code for life: