You've replaced a "could be costly" (rewrite if we need to) with a always costly (over engineer for expansion).
Also, when you don't know the requirements completely is the prime time to do/write as little code as possible. You can't know future and guesses are more often wrong.
You should really push back on teams managers that ask you to write code without telling you what that code should do.
Learned over 25+ years of professional dev xp. Coding for 39yrs.
Thanks @njharman , how does one consider between rewrite vs expand when it is known that some requirements will be true not for the current release but 2 or 3 releases down the line. Would you still prefer rewrite vs expansion? The reason I ask is I got severe pushback recently where I proposed building generic enough components and infra to go along with it that could have satisfied the requirements for the next 2 or 3 releases
In my experience, reality is unpredictable enough that no one actually know what the requirements will be two versions down the road. In practice you end up with code that is more complex than what the current problem needs, trying to solve a future need that you presume will happen but you don’t really know what it is and when it will happen.
You've replaced a "could be costly" (rewrite if we need to) with a always costly (over engineer for expansion).
Also, when you don't know the requirements completely is the prime time to do/write as little code as possible. You can't know future and guesses are more often wrong.
You should really push back on teams managers that ask you to write code without telling you what that code should do.
Learned over 25+ years of professional dev xp. Coding for 39yrs.