Within the games industry, it has sometimes been my experience that the practice of designing and implementing frameworks for reuse and / or generic toolsets is really a symptom of something else in disguise, namely that you don't know what it is you're trying to create. This means you don't really know the requirements / design constraints of the application you are trying to build. So you put it off and build a generic application that can be flexible down the road. Check out my earlier thoughts along these lines in a ranty potential section of my book.
This is actually worse than just sitting around doing nothing, because oftentimes the generic codebase that you build (that is "future-proof") just gets in the way once you get your game design together (isn't really "future-proof" at all), and every single game design decision that you didn't anticipate frustrates you as it feels like it "breaks" your beautiful system. God knows I've done this myself; I think that Ground Control II was the project on which I finally just let go of trying to anticipate which way the system would go, and amazingly things just got better with that "slacker" mindset.
Ironically, right now I'm running the risk of doing it again, namely with my test project The Swörd. I've recently got to the point where I had all of the features that I knew I wanted, and thus sort of ran into the inevitable wall of "what is all this stuff for?". Thankfully, I think that I'm getting better at figuring out where that wall is, and so as long as I don't have an application in mind, I'm not going to develop that stuff any further.
With that said, I will end this entry on a somewhat mysterious note...