Let’s talk about frameworks: When frameworks aren’t right

Published: June 10, 2006. Filed under: Frameworks.

I know, I know, I said I was done with the series. But there’s one more thing I’ve been feeling like I should have mentioned: when frameworks aren’t the right choice for a project.

The big belly, revisited

A simple line graph which steeply curves upward from bottom left, then levels out and is mostly flat through its middle, then steeply curves upward again toward the upper right

Remember that image? It shows the types of projects for which I think frameworks are a good choice, the 80% or so of web projects which can all be handled by a database-driven application and gradual scaling of the hardware. Which, logically, indicates that other types of projects — basically, those which aren’t in the fairly flat region in the middle of the graph — aren’t ones where a framework should automatically be a candidate.

That’s not to say you can’t handle those projects with a framework, just that depending on the situation a framework could be overkill, or could be missing too many things to justify its use — hacking additional features and support into a framework may end up being more costly than writing a new application from scratch.

One of the best quotes I’ve ever seen about frameworks appeared, of all places, in a comment posted to Digg:

Rails (and Django) just makes life easier by combining all the stuff you *should* have been doing but never really got around to (unit tests, MVC separation, humane URLs, etc.). You still have to make a web application, you just don’t need to write an ORM, a templating system, a URL mapper, etc. etc. before you can get to that. It’s the difference between having to build a kitchen before making a cake and just showing up with some flour, sugar, and eggs.

Do you need a kitchen?

On the leftward end of the graph, there are a lot of projects that don’t. To extend the analogy, on these projects you may be able to just go down to the store, buy the cake and eat it without ever doing any cooking at all. These sorts of projects might include:

Is a standard kitchen enough?

And over toward the right side of the graph there are projects where the kitchen won’t cut it. If you’re baking a cake, a typical well-stocked household kitchen should have most of the things you need. But what if you make wedding cakes? Or what if you’re a bakery? Maybe you need to bake fourteen cakes at the same time, or bake fourteen different pieces for one cake. Then the standard household kitchen just doesn’t cut it.

The same is true with frameworks: some things are just too much for a generic framework to handle well. That’s not a failing in frameworks, just a side effect of their target market. A better analogy might be to think of a four-door sedan and an eighteen-wheel tractor-trailer — the fact that the sedan can’t carry twenty tons of cargo isn’t a failing, it’s just a side effect of the market it aims for. And there will always be people who need to carry twenty tons of cargo around, so there will always be a market for tractor-trailers.

This one’s a little harder to pin down with typical use cases, because I don’t know if there are as many use cases. But a couple do come to mind:

Note that in both cases, the limiting factor is not the amount of data or the amount of traffic, it’s what you need to do with the data. In both cases, that’s so extremely specialized that no tool which is generic enough for the big belly is likely to be able to support your needs.

And sometimes you really just need a good cook

Also, I feel I should point out that, while frameworks do encourage some good programming practice, they can’t replace good programmers. Or good designers. Or good DBAs. I’m not picking on anyone in particular, and I’ll exaggerate the examples to make sure that’s obvious (and because it’s funny), but sometimes there are poor people, poor processes or poor applications in place already, and a framework can’t do anything to fix that.

Some examples and proposed solutions:

See what I meant about exaggerating?

Humor aside, I really want to drill that point home: no matter how good a framework is, it can’t solve problems with your organization. It’s not a panacea, it’s just some libraries of code.

And that’s a wrap. No really.

And now I think I’ve covered this topic pretty exhaustively. Tomorrow it will be time for something completely different.