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?
--
AnonymousDonor
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