I absolutely agree with this. I always like to say, the best way to make code extensible in future is to make it do its current job as simply and clearly as possible.

If you leave a hook in for some feature you "know" is coming you'll only screw it up - either that feature won't be needed or it'll look different than you expect. Your field validator is a great specific example, I think I'll use that one in future.

(A corollary of this though is that you have to be happy to ruthlessly refactor existing code when a new requirement actually does enter the scene, because of course that requirement was deliberately not prepared for in the existing code.)

Programming in my world is about anticipating abstractions, without actually abstracting. We write code for it to be changed. We know to a certain extend how the specifications, design and code are likely to change over time. We anticipate the kind of abstractions needed to accommodate that change.

This in turn influences the choice of programming language, unit testing, naming, modularization, infrastructure...

Just as a simple counter example: I write my code so I minimize the amount of state and provide good type information. The advantage is that future (re-)composition in other abstractions of the code will continue to work.

If your familiar enough with the problem, you can usually predict fundamental requirements and design in anticipation of them.

I think there is an important difference between anticipating abstractions and actually abstracting.

In your example, you were actually implementing an abstraction and anticipating a future use. That is something completely different.

What I am trying to bring across is: there are multiple 'simplest' solutions. It helps to know how, in the future, you are expecting to abstract away from that solution to newer 'simplest' solutions.

For example, one might want to use a FP-ish approach, because simplest solutions within that space tend to abstract better than an OOP approach. Or in the recipe example, we could have modeled the steps as objects with dependencies. Given the right programming language, that solution might be as simple as the OP, but provide many more extension points.

This is the essence behind YAGNI. I think it's something everybody disbelieves to begin with and only learns through suffering the pain of their own mistakes.

At least, I've really struggled to convince people that it's true until reality hits them in the face.

Thanks. I intentionally stayed outside of the business domain, since I believe it is a subset of the problem domain. But, then again, I agree the orientation should be around the added value and as such, most likely, the business domain.