The framework you want is not what you think it is

In an interview on Artima.com Erich Gamma says: Well yes, I matured too and XP reminds us that it is expensive to speculate about flexibility, so I probably wouldn't write this exactly this way anymore. To add flexibility, you really have to be able to justify it by a requirement. If you don't have a requirement up front, then I wouldn't put a hook for flexibility in my system up front.
I've worked with several teams who wanted to add all kinds of hooks today for flexibility that might only pay off tomorrow. This may be a symptom of having been burnt by changing requirements in the past, a response to blame that says "Well they said it should have been more flexible!" Or it may signal a lack of comfort in the whole incremental delivery model that underpins Agile software development.
One team I can think of wanted to put off writing all the customer specific code until after they had written a flexible framework for the application. Did they really want to write a framework? Probably not. The team were really quite committed to delivering something valuable to the customer, they just felt they needed to spend a lot of time creating loosely coupled abstract base classes in order to do this. My job was to show them that the framework they thought they wanted was really just a design that could be allowed to emerge.
As Erich puts it: Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it. It's fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it's difficult to bend the framework in a direction it didn't anticipate.