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.
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.
When I work on my pet projects I want to maximize my opportunities for learning. I choose no framework if I feel I can pull it, or a smaller framework if that would be too rough. This is a low speed, lots of fun strategy.
If I take on a project where the goal is to build an MVP, I choose one of the bigger frameworks. The project may not live to see its sixth month, and the main goal for the business is to prove enough viability to extend the life of the project. Big, heavy frameworks  allow fast progress in the short-term, contributing to the chances of survival for the project. If the project indeed survives, any developer coming after this stage will welcome some common ground, and following the guidelines of a framework certainly helps.
When a project passes the MVP stage, we can assume that the business side has figured out the market fit and product focus, there is some hindsight on the technology direction, and we can pay some of the technical debt. This may be a good the time to extract some services from the application, replacing smaller libraries for the monolithic framework, or even growing some of those libraries in house.
For mature applications, or those few projects where there are enough resources to focus on the long-term, it may be beneficial to introduce a smaller framework , and mix and match some external or homebrew libraries to complement it. A set of small, cohesive tools will still allow us to tweak our course as we gain a deeper understanding of the problem domain. Small, good tools can be combined in unexpected ways to build bigger components to support our growth.
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.