Frameworks and the Tyranny of Fear Driven Development

Frameworks. In the technology industry, this is a very polarizing term. For some, it represents a “work smarter, not harder” ethos. Yet, for others, it represents following a “blind faith” from metaphoric Ivory Towers. No matter what your stance, frameworks are a reality in this industry and have both helped and harmed developers in their quest for productivity.

This article represents a meditation/confession of sorts from me, a recovering “framework junkie”, and my realization that perhaps an anecdote I once heard rings true as I continued my technological journey: “You use libraries, but frameworks use you.”

Good Intentions, Generally Speaking

This is not to say that frameworks are intentionally created for nefarious purposes. For the most part, their creators have the best intentions for developers. Since technology moves so quickly, frameworks generally serve as bridges for developers to apply familiar skills to new platforms. In practical example, this can be seen in the proliferation of MVC frameworks in the platform of your choice. An important key to mass adoption is a sense of familiarity.

You Can Have It All

On top of familiarity is convenience. When you start off with a platform in its infancy (for example, Node in 2009/10), there’s a lot of “rolling your own” headaches. Any logical person would ask why we need to reinvent the wheel. Frameworks provide this convenience, giving the developers all the tools they could possibly need and then some. The hook is that we get to focus on building products, not infrastructure. Doesn’t it feel great to have somebody watching your back?

Trust Us, We Know Best

Then, something strange happens. Developers start to consider the framework creators their high priests. Trust equity has been rightfully built through the goodwill of providing a great tool for the community. This in and of itself is not a problem.

The problem arises when developers subvert their own hard-earned technological fundamentals in favor of the mental opioid of using their beloved frameworks. Strange thoughts enter the brain of an otherwise logical person. The framework takes care of everything, why do I need to care? Why do I even need to bother with the “mental load” of worrying about “lower level” things?

Developer De-evolution

Without even realizing it, legions of developers become dependent on a framework, not unlike addicts to a vice. Rational thought gives way to willful obedience. You hear worrying statements, such as “the [framework x] people are smarter than us, they’ll figure it out” or “if it’s not done like the [framework x] way, it’s not right.” Pragmatic ideals ossify and dogmatic values emerge. We often joke that developers get into religious wars, and, in terms of the fervor you see in technology debates, this is not very far from the truth.

Fear Driven Development

Taken a step further, like any good “religion”, fear is at times used to augment framework devotion. A key selling point of any framework is the removal of worry. “Don’t worry about [technical discipline], let [framework] take care of out Our Way.”

The inverse can be applied to instill fear that you sometimes hear from evangelists of frameworks. Stop using [framework], and watch your worries compound. “Do you know [technical discipline] and how to prevent against [attack against technical discipline]?” Not only do developers become subservient and irrational, but they also become fearful.

This is not to discount any of these worries, as some are legitimate depending on your problem domain. The point is to not let these worries be the primary driver of a developer’s decision making process.

Thinking of a Better Way Forward

So, if going the framework route whole hog is generally not a good idea, what are the alternatives? How can we get:

  • A level of consistency with familiar patterns
  • A well maintained foundation
  • The ability to extend any parts of the foundation
  • Not be “locked in” to a specific opinion or pattern
  • Enough consideration of “low level” ideas without mental overload
  • A sense of peace at knowing what you’re opting into

Strength in Numbers

We see present examples of how to effectively move away from frameworks in this “happy medium”. Instead of one monolith, you compose a series of purpose-built libraries that follow similar patterns and can essentially “bolt on” to one another. This can be seen, for example, in Node ecosystem, where purpose-built libraries form a fully scaffolded, modularized system. In the front-end, we see this happening in the React ecosystem as well. Thus, your solution is less Robeast and more Voltron.

Furthermore, thanks to places like GitHub, developers have more visibility into the decisions made for specific libraries. Even more empowering is the ability to effect change in these libraries by contributing PR’s to individual libraries. Developers no longer have a giant bureaucracy of a framework vision to navigate in order to see features they desire.

Ecosystem as a Framework

In short, a platform ecosystem can serve as your “framework”. The big fundamental difference is the agility this approach affords you versus awaiting releases from the Ivory Towers of frameworks. You are not reinventing the wheel of “lower level” work, but instead are choosing from options that solve these problems.

Some may consider this as “rolling your own framework”, to which I would disagree. Much of the lower level work has already been done, and your job as an architect or developer is to opt into the proper options for your problem domain. The cost of freedom is essentially to become a better critical thinker. To me, that’s not a cost at all, but instead, is a good virtue to adopt as technologist.

In Short, Don’t Be Afraid to Level Up

If there’s anything that being a “recovering framework junkie” has taught me, it’s that convenience comes at a price. There is no such thing as a worry-free solution. Fear should never be the primary driver of your technological decisions. The best defense against the worries you have for your system is to become a better pragmatic, critical thinking developer.

While I do believe frameworks serve a role in platform adoption, their usage should be in moderation, much like sugar for your diet. They’re great to get you started, but be wary of addiction to them, as they will inevitably take from you more than they give.