Let’s talk about frameworks: When frameworks aren’t right
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
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:
- Anything that’s going to have content which almost never changes, and which almost never adds new content. If it’s already in its final form, a dynamic database-driven application just doesn’t make sense.
- Any kind of “brochureware” site that will update occasionally and really only needs to manage a few flat pages. There are plenty of simple CMS applications which can handle this (my personal favorite would be Textpattern, which can handle more advanced usage as well if you need it in the future) and which can be taken off the shelf. Though of course Django‘s built-in “flat pages” application can do this too, so it’s really a question of what you’d prefer.
- A blog. Yes, I’m running a Django-powered blog. A lot of other people are, too. And a lot of people are running Rails-powered blogs. But for plenty of situations, “turn-key” blogging solutions work. You can get a free account at Blogger or LiveJournal and be off to the races. Frameworks start making more sense when you want to add more features — the total code you end up writing may be less than hacking those features into an existing blogging application.
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:
- Banking and financial services. Here it’s not so much that a sedan won’t work, but that what you need is an armored car with heavily-armed guards and built-in satellite tracking. A typical framework will probably handle the database side of your application pretty well, but you’re going to need levels of security and auditing far above and beyond what other web-based applications need. Not only would it likely involve a lot of work to bolt that on to your framework of choice, it’d probably also be a very bad idea in the long run: the most secure solutions tend to be ones which have been developed by domain experts and, more importantly, extensively analyzed and tested by the industry over time. Re-inventing the wheel by strapping additional security and auditing onto a framework throws that away and bets the bank (literally) on getting everything right with the first try.
- Search engines. Large-scale search is such a thorny problem and so very difficult to do well that you’re going to have to engineer things from the ground up, especially your database operations; SQL, no matter whose implementation, is probably going to be far too slow to be of any use, and likely doesn’t offer anywhere near the level of algorithm optimization you’re going to need.
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:
- Your application will involve forty-seven abstract base classes, twenty-three of which are models; all other models in the application will inherit from at least six of these classes. If your proposal looks like that, please check yourself into the nearest psychiatric hospital for treatment.
- You have legacy data as follows: five models in an Oracle database in California, six in a PostgreSQL database in New York and eighteen in a MySQL database in Chicago. The Oracle database includes a table which contains data related to every other table in the entire system and which has a sixty-five-part composite primary key. If your legacy application looks like that, hire a DBA and a hitman. Have the DBA redesign and normalize your data storage, and have the hitman kill the person or persons responsible for what you have now. In the long run, this will be cheaper than the cost of maintaining your present system.
- Your proposal invcludes the phrase “Singleton pattern” anywhere. The solution to this is to read Steve Yegge’s rant on Singleton over and over until you are enlightened. If enlightenment fails to occur, ask him nicely to come hit you with a big stick; in Zen stories that usually works.
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.