experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity.

I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.

You have to be pragmatic about it, balancing between the speed of only implementing the now and the flexibility of taking care of the future. It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) and and either accepting it or ensuring that it will not happen.

> It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications)

This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the <future> consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

Risk management is a fact of all activities. It's not predicting that some thing is going to happen, but it's evaluating that if we can afford the consequences if it really happens. If we can, let's go ahead with the easy choice. If we cannot, let's make sure that it won't affect us as much.

> Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

Those are solutions to real problems. The real issue is the cargo cult, aka "Google is doing it, let's do it too". If you don't have the problem, don't adopt the solution (which always bring its own issues). It's always a balancing act as there is no silver bullet.