“Let’s not worry about the future and stick to the specs, please.”

Or as I like to call it:

The reddest flag in a bad manager.

Tbh, that sounds like pretty sound advice to me. Over-engineering beyond what the spec requires in a vague attempt to predict future requirements is something that very rarely pays off.

Specs are specs. If they are flawed, you tell the man responsible for specs and it's not your problem anymore.

@molaram @AlmondSauce depends on the scope! To give some examples which really happened to me:

1. Someone on Wordpress assumed that articles will never have more than one tag while having external editors, wanting to implement a feature that would and did break as soon as an editor used 2 tags

2. Multilanguage at the beginning of a project: relatively low cost to implement at the beginning of a project, huge cost to implement in the middle of one

@piratefox Sure, it depends on how much of a trade-off you're talking about - but even then, it's something you raise as part of the initial requirements as to whether they want you to cover that use case, make sure they understand that this is a low-effort thing now and will be high later, get it in writing as to whether they want it or not, and then proceed according to the spec.

If they then turn around and then change their mind, you just quote for how long it'll take, and then proceed as agreed when you can fit that work in. If they complain it's going to take ages, then you point them back to the original emails, and show them in no uncertain terms this was a decision of their making.

In a way I’m glad I’m not working on anything major atm

This actually happened in a Discord Voice Call. Was working on a Scratch Project with my colleges and someone suggested that we dont worry about debugging the projects and just worry about adding MORE CODE which just piles up on the debugging list.

@TheBigJoe1489 MOAR