Get yourself a framework

Published by Lorenzo Planas on April 21, 2014

It's intriguing how much we are fascinated by frameworks: I guess most developers use at least one framework on a daily basis. Most of us want to or have built a framework, with varying levels of success. There are frameworks for building web applications, user interfaces, dealing with databases and whatnot.

What motivates us to build and use frameworks? We programmers dream with solving a problem once, and cashing in on our solution everytime we face the same problem. Other programmers facing similar problems stumble with a framework, and use it for a quick win. Quicker than building a solution by themselves anyway, since all libraries and frameworks require some integration effort.

tools Photo credit: "Old tools" by spinster cardigan

We love installing new stuff, we crave quick fixes, and we look for the approval of our peers ('the community'). Frameworks provide all of this, and it's just too easy to get hooked into them.

Most industries encourage the division of labor and specialization, so we take on projects with problem statements within our area of expertise. Since their context is similar, it makes sense we use the same framework for all of those projects, specially if there are previous success stories in the team. This framework was such a win in our last project. And everybody is using it. It's great. Look, we are two weeks into the project and we have already completed 80% of the features.

It's a matter of time we take on a project which deviates a bit too much from the framework's sweet spot. We can't believe this great framework is so convoluted. How couldn't they think of this? This framework sucks. It's way too bloated. Let's look for something simpler. Heck, we know our problems better than anyone, let's build our own.

We love frameworks, and we hate frameworks. It isn't rare that our feelings toward one framework or another change over time. We could certainly benefit from making our relationship with frameworks less emotional.

A framework for choosing frameworks

I started programming profesionally for the web after a career in information security and risk management. My preferences (read: prejudices) are skewed toward smaller frameworks and homebrew libraries. I'm trained to reduce external dependencies as much as possible. With a special focus asymmetric dependencies, where we don't have leverage on the other party. Still, choosing frameworks and libraries for a project is an important decision, and I try to balance my preferences with the business and technical contexts of each project.

Decisions need context

Popular frameworks have extensive documentation on their benefits and how to use them. But we know little of the context where they were created: what were the business needs, the technology constraints, the timeframes, the skills of the team involved, their pain points in a very specific situation. That information would help us to choose wisely, and avoid a far too common problem: arm-twisting a framework to solve problems outside its intended use cases.

Inside every framework or library there is some innovation. Reading their source code is a great way to learn, even if you don't use or like a specific framework. Frameworks are made by people smart enough to stop and think about their problems, and then try to build a solution they or others could reuse. A story, an epic on that effort would remind us they are developers like us, doing their best with what they have. It would reduce blind love, and it would reduce blind hate.

[1]: Examples are Rails for Ruby, Django for Python, Spring for Java and Ember for Javascript in the browser.

[2]: Examples are Sinatra for Ruby, Flask for Python, Play for Java, Backbone for Javascript in the browser. And many others.