So, to me, "future proofing" has some very specific connotations. It doesn't mean building for eventualities that you know will happen and already know how to b

So, to me, "future proofing" has some very specific connotations. It doesn't mean building for eventualities that you know will happen and already know how to build for (though, if it takes extra time to do so, you do need to be mindful of the cost of delay), and it doesn't mean things like writing well factored and loosely coupled code (within reason) so that you get a system that's generally easier to modify. It means going out of your way to try and handle scenarios that you don't know will occur, or whose details you don't really understand yet, with clever one-off facilities. E.g., I've come into a couple projects now, where I'm supposed to add in some new feature, and I discover that the original author has thoughtfully added a bunch of extension points to try and help me with that. Both times, I also discovered that building in those extension points accounted for a large amount of the pre-existing complexity in the code, even though they weren't actually being used for anything yet. And both times I also found that none of them actually addressed my needs, so all that extra effort and complexity was a waste. One time I was unfortunate in that the existing code was of the "600 line functions and a whole mess of mutable state and temporal coupling" variety, so changing it would have incurred excessive risk, and I opted for just jamming my square peg into that round hole. The second time it was well-factored code, so it was easy enough to rip the round holes out to make room for square ones. But it would have been even less effort if I could have skipped that cleanup step and just jumped straight to adding the extension points.