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!

Framework + Language Attention Deficit Disorder

I love technology and love playing with the latest and greatest (which being ‘latest’ always means there’s something new to play with.)  In the wee hours of night after work, I’ve been playing with various frameworks and languages for a few of my side projects and discovered that I have fallen into this rut where I keep reimplementing the startup idea I have in different languages.

First, I tried to create my own framework.  That, as it became painfully obvious, was not the best idea ever (even though I’ve done that for the full time job with a team.)  When reinventing the wheel though, its best to look out there and see what else is avaible.  At least be influenced by it.  This is when my ADD kicks in something fierce.

I played with the following: Wicket, Tapestry, Rails, Grails, Zope, Restlet, Django, Rails on Java, and JSF (ICK!).  The saddest part is that, depending on the framework/language, I’ve developed pretty large core pieces of functionality in many of those frameworks.   Then I threw them out!  I guess one positive of all this back-and-forth is after playing with these frameworks, I can feel pretty confident about the one I settled on (Django), but even now I have pings of “let me try something new!” (or flipping back to Grails occasionally.)

Anyone else have these ADD issues with frameworks and languages?  How do you end up settling on one?

If anyone is interested, I can talk about a few of those above (why I went or didn’t go for them.)

Django+Eclipse with Code Complete Screencast

Here is my first screencast, finally polished off.  In it, I discuss how to set up the Eclipse IDE to do your Python and Django development, complete with code complete, jump-to-code functionality and live  breakpoints + code replace.  I’ve recently migrated away from Textmate (a large reason for this was wanting to develop on both Linux and OSX) and found that Eclipse has really sped up learning Django and some of the libraries I’ve used.
I reference a few URLs for this screencast.  They are:

I also reference a chunk of code that your manage.py should be.  I’ve uploaded that to snippet to django snippets.  It was originally posted here in 2007, so I’ve copied it to Django snippets in case that post disappears.

With that all said and everything out of the way, here is the video.  Please let me know if you have any questions! (In case you’re wondering, I used IShowU HD Pro to record this and iMovie to edit [badly].)