I think that frameworks fit very well into XP.
''[See ExtremeFrameworks.]''

There are two ways to develop frameworks depending on whether
you know how to develop it already.  If you already know how
(in general) to make a particular framework, you can develop
it like any other application.  The test cases are little applications
that use the framework.  This is how I would do a drawing framework or
a persistence framework.  In fact, I did a persistence framework like
this a few months ago.

If you have never created, used, or studied a particular kind of
framework before, you are better off developing applications first,
and refactoring them to create the framework.  A framework is a
reusable design of part or all of an application expressed as a set
of abstract classes and the way instances of those classes collaborate.
In general, abstract classes should be created by refactoring a set of
concrete classes.  Build one application, then when you build a second,
refactor the first to make the first iteration of the framework.  Use
the framework to build a third, refactoring the framework again as 
needed.  By the time you build a fourth, it is probably in pretty good
shape, though the only way to know for sure is to try and see.  If not,
keep building applications and refactoring until you don't need to refactor
any more.
-- RalphJohnson

----

On good days, I look at the DefinitionOfFramework, I know what one is, and I'm happy.  On other days, my eyes get all blurry and I see only Types and Instances.  I end up with the notion that a framework is a piece of code with holes in it.  The filling of the holes provides new capability.  The framework uninstantiated is an abstract Type.  Instantiated, the framework + the code called by it is a Subtype of the framework.  Any merit to this ungodly propeller-cap spin?
-- MichaelFeathers

-----

Hmm, the conversation in my head when thinking about a framework is, "Generically, this kind of object asks that kind of object for xxxx.  Then that has to get the specific yyyy from the first..."  This generic/specific conversation is what tells me what goes up the hierarchy, what goes down.  I understand the holes in code view, but it doesn't give me much active help.  
-- AlistairCockburn

''This generic/specific conversation is described in the "Nested Framework" in PatternLanguage FrameworkConstruction (http://st-www.cs.uiuc.edu/users/hanmer/PLoP-97/Proceedings/shai.pdf).''
---
Is there a NestedFramework elaboration that is local, or at least not an evil, throbbing pdf?
-----

I feel that "framework" is overused and frequently implies dependencies that one may 
really not wish to have.

--JohnHarby

Step one: Don't.  -- AndrewMccormick

----

We all talk of Frameworks today, knowing that there is a lot of TechnicalDebt, complexity, design and effort. What if building Frameworks, coalescing Design Patterns were simpler and the tools vastly superior? We could potentially be building Frameworks, as simply as building a Class.
"'a class is to object', as 'framework is to application'" 

How to develop a Framework is one of the most interesting questions we could attempt to answer. It has always been this 'harder', more 'complex', 'rebellious' brother of the Application. We struggle in building software where the software assets have flimsy strands for relationships. A contract of all or nothing. Software assets need to have better defined stronger or weaker relationships. DependencyInjection, HotSpots, PluggableObjects all need to actually be defined as a standard. Then our future will contain systems which would interoperate far beyond our current tools could provide. The next level of abstraction for software lies in a common framework. -- JonathanCrossland

----
[CategoryFramework]