[namelosw]

Don't design for future use cases, unless it's a library that may be extended. Instead, write concise code.

Modify the code when the use cases change. In most of the times, open-closed principle is a trap.

However, over-engineering is not only a technical problem. It's more of a problem on project / people / finance, here are some examples but it would definitely not limited to these:

1. The margin is big and the team is big, so we need to keep these people busy.

2. The current stakeholder will cover the budget these iterations until we finish these features. after that, the maintenance costs maybe partially falls on us, or there's will be no budget at all. The less problems in the future, the better.

3. The current budget is for functionality A and someone pays it. And we plan to implement another feature B that is similar to these, and the budget comes from our own. Better make the solution generic so we can use it almost for free.

4. The list goes on...

Better fix those root problems first.