In Defense of Frameworks

Well, it’s been awhile again.  Hi everyone (insert excuses about work, time, etc.)  Anyways…

I’ve seen a lot of posts and comments on reddit lately talking about how using an out-of-the-box framework (Rails, Django, Cake, Grails, etc) doesn’t really buy you anything, and might actually harm you in the long run.  Most of these arguments tie into the 90-10 rule where you’ll spend 90% of your time on 10% of your code (the unique part your site.)  At that point, you need to optimize, scale and focus your energies on these parts of the site, and the framework will inevitably get in the way (see Twitter.)

I see some merits in that argument, but I don’t know how much I buy it.  There are a few things that frameworks do get you, and in the end if you’re writing something to last, you’re going to be building a custom framework anyway!  So, here are my reasons as to why frameworks aren’t bad.

Rapid Iteration/Bootstrap

Yes, I know… when you’re Twitter things like Rails’ ActiveRecord starts to suck.  But, you need to get TO Twitter before you start worrying about those types of optimizations.  Even if you know your site is going to have a steep growth/adoption curve, you still won’t gain much by writing everything from scratch.  No matter how brilliant you are (and I know you’re brilliant!), there is an incredibly high likelihood that you won’t even know what exactly will be the bottleneck once your users start using the site.   Who knows?  Premature optimization is an evil bitch.  You can spend months optimizing the database schema and perfecting your Hadoop map/reduces and then find out that your site’s JavaScript is killing computers that are slower than that quad-core under your desk.

Free Stuff

If you go it alone, you’re setting yourself up for more work in the long run.  Sure, there are libraries out there, but you are responsible for their integration.  You’re responsible for best practices.  Meanwhile, framework users can easily leverage the community for improved backends, plugins and templates.

Free Improvements and Core Testing!

A corollary to that is you get free improvements when you use a framework.  Upgrading to a newer version of Django will give you a slew of upgrades and performance improvements that cost you nothing more than a regression test of your software on the new version.  It’s a great pick-me-up for your site.  Also, you get free security patches (although at the same time, a large framework is more of a target than your own code) and the confidence of knowing that a slew of developers and users have run their own unit tests (not to mention running the framework in their production!)  And of course, if your site does become the next Twitter, just as many people will be trying to hack you as Rails.

A Common Vocabulary

Another amazingly useful thing about using a standard open source framework is you can leverage the community for help and recruiting.  Having a conversation with another developer using the same framework provides a common vocabulary that allows you have to amazingly efficient conversations.  “I am having some difficulties integrating Twitter OAuth as an authentication backend.”  “Did you try a signal?” etc etc.

Related to this is, its much easier to hire and bootstrap new employees when you are using a framework out in the open.  Throw a Django or Rails developer into your large codebase, and sure there will be some ramp up time (your architecture, custom code, hacks) BUT you will have a common starting point.  Throw a person into your custom framework and the ramp up will take considerably longer.

Finally,

You’re Going To Write One Anyway

If you decide to go it alone, you’re going to end up writing your own custom one anyway.  Now, I know for most developers it’s more fun to start your own from scratch instead of leveraging one out there.  Additionally, most developers find their own framework better.  50% of the time its just because they know it better.  They know how to hook into since they wrote it.

At work, my team wrote their own custom closed source CMS and Framework.  Sure, it works great and covers our needs, but I see these ramp up problems all the time when we hire people.  I also know that, if my team doesn’t update or secure the framework, nobody else will do it.  Instead of just developing our own site now, we also develop the framework.  This is possible because we have a team of developers, so we can split our time.

But, if you’re one guy working on a side project (or the gestation period of your startup), use a framework.  Sure, you’ll end up spending 90% of your time on that 10%.  Sure, you might be cursing a ‘limitation.’  But, for the most part, the reason you only need to spend another 10% of your time on the other 90% of the code is because it’s already written for you!