Frameworks Considered Harmful

Please add your experience with frameworks below.

I don't think there is an official XP position on Frameworks. Look at them in the light of the values: Simplicity, Communication, Testing, Aggression. I personally distrust frameworks, mostly on the basis of (anti) Simplicity. -- RonJeffries

Before choosing to use a framework, it's important to consider the cost. If the framework is any good, it will be capable of doing a lot more than your project actually requires. This means, for a big chunk of the framework, YouArentGonnaNeedIt.

However, with a framework, you can't just remove the stuff you don't need. This would make you responsible for maintaining (your version of) the framework and you got the thing to save costs. So you gotta live with it.

The human cost of living with it comes from:

cost of learning. If the framework is well-factored, and well-fitted to your application, this can be a reasonable investment. If not, it can be very hard to learn how to use it.
cost of use. If it's easy to use, again this can be reasonable. If the framework really isn't well-suited to your situation, using it can be quite burdensome on the developers.

The machine cost of living with a framework comes from its size and performance. Often, but not always, a framework's code will be bigger than what you would have hand-crafted for your app, and because of its increased generality, it may be slower. (There are definitely some exceptions to this.)

Your mileage will vary from one application, and one framework, to another.

Not all the ones I refer to below are 3rd party, but many are, because that's been my experience. I'm inviting others to add more commentary.

In-house frameworks need to be developed as RalphJohnson describes in HowToDevelopFrameworks. Too many in-house frameworks are developed in a vacuum, with zero applications. I'd take up programming in C++ before I'd use one of those.

Here are some examples and opinions:

Graphics frameworks can be a good bet if you have a graphics-intensive application. This is a well-understood area, with serious performance requirements, and the good frameworks solve the problems well.

Object Database frameworks can be a good bet if they are fitted to your app. If GemStone is a framework, I'm all for it. I (RonJeffries) have used smaller persistence frameworks, and they wound up being too slow and too large compared to custom serialization.

Relational Database frameworks can be a good bet if you need access to something like DB2 from your application. It's not an easy problem and there are good frameworks out there.

ReportingFrameworks are iffy, especially if you don't have an app that is mostly reports. You may need a reasonable number of small reports that would be better programmed directly. As number and complexity of reports increases, value of reporting frameworks goes up. Requirements for HTML formatting or Rich Text Format are also indicators that you might want a framework.

I/O frameworks, frameworks for reading and writing various general file formats, have a good chance of having far more functionality than you will actually use. The rest will be wasted.

Testing frameworks, frameworks for automating UnitTests and AcceptanceTests.

Contributors: RonJeffries and others

Ron and others,

While I go happily along with a lot of the Extreme Programming ideas, I have this nagging question which comes particularly to mind in this page: Smalltalk (which I dearly love) is one of the original Swiss-army-knife frameworks, and VisualWorksSmalltalk is one of the most over-engineered (except for VA) examples of more-weight-than-you-will-ever need. Yet XP apparently requires such a framework for some of its advantages. Am I missing something, or should you be using SqueakSmalltalk?

-- BobHaugen

Briefly: a Swiss army knife isn't a framework, it's a tool. Ditto Smalltalk. When I think of a framework, I am thinking of a collection of classes (subroutines?) with some special purpose, such as reporting, access to SQL, creation of dynamic HTML.

While VW is over-engineered to my taste, it was also the most robust product-like Smalltalk available at the time we started ChryslerComprehensiveCompensation. It's a good base for most everything, IMO.

By my "definition", the closest thing to a framework in VW is the windowing stuff. Which I hate: there's too much of it and it's too complex. Or is it just me? ;-> -- RonJeffries

The point was not about the definition of framework, but an apparent contradiction in XP: that the practitioners depend on VisualWorks, "a good base for almost everything", which seems to be antithetical to the tenets of XP.

Now, I have nothing against being contradictory, it just seemed to merit some reflection. Does that mean there is a place for over-engineering? That XP is appropriate for work-for-hire, but not for (whatever VW was designed to be)? Does the thought cause you some cognitive dissonance?

-- Haugen

None. Which of the XP tenets do you feel might be violated by using Smalltalk or VW Smalltalk? (Actually we use GemStone, btw.) -- Ron

None. But VW Smalltalk violates the tenets of XP, having more of everything than anybody ever needs. It might be an advantage for MinimalMethodologies to feed off a rich base of re-usable code. But I think that the people who developed all that re-usable code had to violate a lot of XP principles. I am really searching here for something that may belong in the ExtremeProgrammingBoundaryConditions discussion: when is it better to do the opposite of YouArentGonnaNeedIt? -- Haugen

When is it better to do the opposite of YouArentGonnaNeedIt? My guess would be: never. If you are building a framework, there are certain things you need because of the remote nature of your users that you don't need if everyone who uses your stuff is in the same room. More effort would go into making classes readily subclassible, into providing hooks, and so on. But you would be doing these things because your requirements said to do them. YouArentGonnaNeedIt is about not doing things because you don't have a requirement. IMO there is no conflict: it is a question of what you are trying to accomplish. -- RonJeffries

But VW Smalltalk violates the tenets of XP, having more of everything than anybody ever needs. VW doesn't necessarily violate the tenets of XP. We aren't against reusable code, we recommend focusing on use, rather than reuse. The result of clear well-factored code is that it turns out to be reusable. Much of how Smalltalk got the way it is, even VW, came about as people built things for their own use. This is good. Other parts were built with reuse in mind. Even that isn't necessarily bad, if that is your mission. XP wouldn't say never to do a project to build a framework. We say don't build a framework if your mission is to build a payroll program. -- RonJeffries

Do I contradict myself? Very well then, I contradict myself. I am large. I contain multitudes. -- WaltWhitman?

Ron and others,

while I can see your major points (e.g. Simplicity and Communication) with frameworks, I do not agree that frameworks should be considered harmful. In fact I believe that frameworks are the most promising reuse-technology available for professional software developers. But you have to use them appropriately! What needs to be considered, are what I call the CriticalSuccessFactorsOfObjectOrientedFrameworks -- PeterMaier

1. If you can buy it instead of writing it yourself from scratch, do so. You'll practically always be better off this way. Don't worry about its internal complexity: You didn't write it, and aren't going to maintain it, are you?

2. An extreme anti-framework position would be... Unix -- big and bloated; throw it out and write a one-off OS just for this app. (Kinda' overkill, isn't it? ;-)

This would depend on the app in question, wouldn't it?

This sounds like the ChuckMoore approach. There's something to recommend it.

3. A framework tends to cause problems if it's ill-matched to your application.

As an aside, it seems TestingFrameworks is a good example of where frameworks can coexist peacefully (if not necessarily) with XP. It seems that in cases like this, the simplicity is increased rather than compromised because of the framework. Why? I think it's an issue of granularity...

Perhaps this is an argument for smaller LightWeightFrameworks? that can be used without bringing lots of baggage. Rather than trying to use/develop large frameworks with thousands of hooks (YouArentGonnaNeedIt), maybe a lighter view would be more appropriate in some cases. The SimplestThingThatCouldPossiblyWork may be in the form of a framework, if that framework is easy, clean, simple, etc...

From my perspective, the reason FrameworksConsideredHarmful is because as a developer, I like to do CoolAndNifty? things in the code. The danger is that I'd be solving a problem that doesn't exist. So it doesn't mean that frameworks are evil in and of themselves, but the use of them tends to be inappropriate.

As far as developing frameworks goes, I think Ron makes a very good point above: ...you would be doing these things because your requirements said to do them. Is another possibility that LightWeightFrameworks? could fall out of the refactoring process?

-- TimWoodard

Who else would argue "ApplicationsConsideredHarmful?"? Some application problems are listed in EnterpriseApplicationProblems, and addressed in DoItSolutions. A framework (platform) that provides a consistent user-interface metaphor ought to be able to eliminate the YouArentGonnaNeedIt accusation that framework bloat is inevitable. (See DoItFramework.) -- JimRussell

For a user of framework, YAGNI still applies because HE is not going to code. The code is there in framework but you can ignore it if you don't want to use it. If the question of YAGNI is regarding framework, then framework was created considering in mind general requirements of that particular domain. So YAGNI applies to framework also if the framework addresses general requirements of that domain and not some special requirements that are needed 1% of time. -- VhIndukumar

I gotta add something here; this is just killing me. I've been doing some "interviewing" of candidates lately (actually, a whole slew of them), and I swear, every single one of them claims to have developed a "framework" of some form or another. I just don't understand where the idea comes in that "If I spend six months developing a 'framework', I'll be able to crank out code to do my work in half the time!" I honestly cannot think of any conceived project that has done such a thing, especially when developed in house... (Hell, maybe it just looks good on a PowerPoint presentation somewhere.) There are a few really good frameworks out there, e.g. JakartaStruts, but someone essentially bastardizing a straightforward piece of the Java API to meet some conceived need is completely, and totally, nuts.)

If I hear more talk from people about "frameworks" and "platforms" I swear...

-- ChadThompson

Chad - if you think JakartaStruts is a "really good framework", I can see why you're down on frameworks. In my experience the promise of frameworks (effort savings) is in fact realizable. Somebody has to make the down payment. I assume you use Struts because you believe it allows you to crank out functionality with less effort than you would expend under some other approach. But how much effort went into the development of Struts? Probably many, many man-months. I agree with your point that companies that are not in the framework development business shouldn't make framework development their business, and I agree with your point that good frameworks are few and far between. But that doesn't mean the idea of frameworks deserves indictment. -- RandyStafford

''People lie in interviews, so you shouldn't believe anything without delving into what they actually mean and what they actually did. But I have certainly worked on frameworks that have saved a great deal of time and that have made changing the underlying implementation transparent.''

Wow. I want to believe you. But, and I am going to echo agreement above with Ron Jefferies, the idea of constructing a framework to handle XXX code just detracts from the simplicity of the design in the vast majority of cases. I did have a chance to delve into how the varied candidates used their 'frameworks', and in all cases, either the framework was a hack that simply hid a lack of understanding of the APIs (a 'data access framework') or simply using the 'framework' moniker to describe a pattern. (By people that worked with other forms of 'structured' programming, but either were not exposed to, or outright ignored, the DesignPatterns literature.)

Why, and let's be really honest, is there such a push to move all development into a 'framework', when it is pretty obvious that such devices are unneeded a vast majority of the time? -- ChadThompson

Because this is not obvious. I consider the socket layer a framework. Do you find that useful or would you prefer that it not exist? Isn't a well thought out API a framework? Now compose an event handling and registration framework with the socket framework and some good stuff is happening.

I'm fairly conservative about the use of frameworks. When you use someone else's framework, you're not just adapting that other person's code, you're adapting that other person's mental model of the domain. Even in a case where the framework is open-source, tweaking bugs might be possible but changing the model is usually going to be more work than simply writing your own from scratch. So the model better be a good one.

A domain is more likely to have well-developed models attached to it if that domain has a certain age, and/or a lot of people using it. Every StarUnit variation is a framework, and I've been happy with the ones I've used because the model of the domain (i.e., automated UnitTesting) jibes well with what I want.

But I'm much less likely to use a framework for a nascent domain. If I were writing code for slurping XML feeds from 5 sources and then sending out customized emails to a user-base, I wouldn't look for a framework to help me with that. -- francis

That is what a framework should be. It should be the embodiment of experience. It doesn't have to be large. It doesn't have to be complex. It doesn't have to suck. It doesn't have to solve all the world's problems and take 2 years to develop.

Since my name is on this page, I might as well actually write something on it.

People sometimes have to program something new, find it hard, and say "I wish I had a framework to help me with this. I think I will write one." The problem is that as long as they think it is hard, they are incompetent to write it.

The time to write a framework for something is when it is boring. "If I have to write another fitzit again, I'll scream!" That is the time you should be thinking about writing a framework for fitzits because you are now qualified. Of course, perhaps the world doesn't need a framework for them. But that is a different issue.

The best way to develop a framework is to refactor an application that you want to use it. Pull the code out of the application into the framework. See HowToDevelopFrameworks. If you are bored with writing something, you must have done it a few times, so it will be easy to find an application that you can use for a start. If you don't have one, you probably shouldn't be writing a framework. -- RalphJohnson

I take a more radical approach where I think 'Frameworks' should be in all projects, whether embedded within an Application, or external for wider reuse.

Usually the friction and views regarding what the Framework 'is', 'does' and 'should be', comes from everyone's different interpretations of ambiguous definitions. Frameworks are almost always implemented from 'mining' common patterns from applications, whether its explicit or 'research' or prototyping. Also certain things considered bad surrounding the Framework topic, like complexity, takes longer, etc, are all based on inadequate tools. In our future, our tools should provide us with Framework building capabilities, utilities and metaData, which would simplify it by making it easier to define its boundaries, FrozenSpots? and HotSpots?. Currently I would agree it is more harmful than not, in most circumstances. But it should actually be at the forefront of our thinking and invention. - JonathanCrossland

What is the Alternative?

Unless you code everything from scratch, which would be cumbersome, some kind of framework, API, or library is required. Frameworks can get you up and going pretty quick, but often don't give you a lot of control. And if they lack a feature you need, you are often SOL.

Semi-related libraries allow you more control, but may be a fair amount of work to glue together properly. I've grown to appreciate good libraries in which the functions are linked mostly by convention, not hard tie-ins. Thus allows one to mix and match and ignore as needed. They are often custom-made over time from both domain experience and personal experience. They get better with time, at least within an organization. But it takes longer to get to this point than a framework.

Individual frameworks usually work well enough. In my experience, it is composing frameworks that causes so many headaches.

See DefinitionOfFramework, YagniAndFrameworks, PrematureGeneralization, HelpersInsteadOfWrappers

CategoryEvil, CategoryFramework