Just a takeoff on the XP page of a similar name. [IfXpIsntWorkingYoureNotDoingXp]
In a conversation long ago a XP guru said he didn't like frameworks because his database framework failed boldly on a project of his. Under further probing a framework was not used at all, the vendor's API was used and when the database failed they were stuck with lots of vendor API code.
From this we get the conclusion it is not possible to learn from experience and create great frameworks. XP strongly discourages creating frameworks and thinking about infrastructure instead asserting it will evolve through refactoring.
Using a vendor's API is not a framework. I've worked on many many frameworks and 90% of them have worked great and have made a very important positive impacts on projects. Most project failures i have been a part of have been because there wasn't a framework. In fact, I've never seen a project fail because of a framework. Maybe it is because I'm careful to keep a framework relevant and not try to rewrite the world, but doing things correctly is an assumption, an axiom, of any process.
For example, I personally don't see people refactoring. Many if not most developers do not refactor and I doubt the ability of most to do so with skill. And for XP to work correctly developers must refactor. If they fail to refactor XP will fail.
The parallel is complete. If you do frameworks poorly you will get poor frameworks. If you refactor poorly then XP tanks. There's no more reason to expect people to create poor frameworks than there is to expect people to refactor poorly. So why is it refactoring can be an axiom but frameworks can not?
I had occasion to hear RonJeffries speak on Saturday, at an XP seminar sponsored by the ACM, and he seemed down on frameworks (he gives similar opinions on FrameworksConsideredHarmful). I definitely agree that there have been some big framework projects (e.g., IbmSanFrancisco and others) that may not have justified their cost, and/or whose results are too cumbersome to use, etc. However I have also had experience where frameworks have saved me tremendous amounts of time and effort, and allowed my projects to achieve results that we otherwise wouldn't have been able to achieve. For example I have used variants of the GemstoneProfessionalServicesFoundationClasses on five different projects now, and they've allowed me to get up and running quickly in every case. JavaUnit itself is in fact a framework. It's not the idea that's bad, it's just been the execution in some cases. Frameworks can't be created in a vacuum, but must be grown. --RandyStafford
Too often are terms confused. I see Frameworks labelled and thought of as libraries and vice versa. If only there was a more definitive way of identifying a Framework ;) The same sort of problem exists for the term "Reuse" which is easily fulfilled by "copy and paste". Although Copy and Paste is reuse, its not quite the level of reuse to which we should all strive! --JonathanCrossland
I see the difference as libraries being something you call and that don't impose particular design decisions whereas frameworks are something you plug into (HollywoodPrinciple) and that control the flow of your logic to some extent.
See also: EvolvingFrameworks, HowToDevelopFrameworks, CriticalSuccessFactorsOfObjectOrientedFrameworks, CompoundObjectProgramming, CategoryFramework