[scrapheap]

Ah, the old "in case we need to do X in the future" line. It's a tricky one as it will always sound like a valid comment, but I've seen so many junior developers take it a face value and feel they have to implement every possible future requirement, just in case...

These days I try to get our junior devs to think of these comments as ETC comments, as the comment was made from an et cetera point of view, but they need to think of it from an Easier To Change point of view. The X they're asking about isn't a concrete requirement, it's just one of many possible future requirements. Putting effort into tackling X is a waste of time at this stage, but putting our code in a place where we could easily implement X, Y and/or Z will usually turn out to be time well spent (as the chances that some of them will be a requirement in the future, we just don't which ones).

In my experience trying to write an abstraction from only one instance of the concept in your code is a bad idea, you need at least two instances of the pattern you're trying to abstract to know what's the abstraction and what should be part of the instantiation.

Instead of falling into the trap of abstracting early, you'll be better off keeping your functions limited to doing "just one thing". That way, when you're asked "what if we need to do X in the future", you can reply with "we should be able to easily replace this function with an instance of whatever abstractions will work best for implementing X, Y or Z"

[lwhi]

The decisions that allow flexibility are usually macro-level decisions.

The overall architecture defines the limit of the solution's scope.

[scrapheap]

> The overall architecture defines the limit of the solution's scope.

Agreed, but the micro-level decisions will impact how much effort is required to work within that scope. Just because your architecture supports something doesn't mean that it will be easy to implement it.