Automagically: Fear of Software Frameworks

Automagically:

1940s: blend of automatically and magically. (en.oxforddictionaries.com)

In application development, there is a tension between the desire to write everything from first principles, and the allure of community solutions in the form of frameworks.  A common objection to both server-side and client-side frameworks is that they have "too much magic", which translates to too much happening out of sight of the developer.  By hiding mechanisms behind some framework-specific shorthand, tasks can be made simpler and quicker for the developer. So why the witch-hunt?

It sounds like a wonderful productivity success, but there are some valid reasons for caution:

• The legitimate need for simplicity in code.  The time saved by a neat framework feature can be more than consumed by one or two sessions of traumatic bug-tracking when the magic stops working.
• The ramp-up time for learning a framework.  Will people really learn to use and understand it, or will they be cutting and pasting snippets of code without regard to negative consequences and interactions?  Sometimes frameworks come and go too fast for anyone to become an expert at using them.
• Opinionated frameworks often start to dictate architecture of application code, for better or worse.
• Bugs in a framework are someone else's problem, until there's nobody fixing it - at which point you've got a much more complicated codebase to bug-fix than you would have been tempted to write yourself.

Reactions against frameworks can also come from an unrealistic desire to know how every moving part works in the final product.  The reality is that everything from device drivers and underlying hardware to programming languages have elements most of us never look inside, and shouldn't need to.  

There can also be an unconscious attempt to slow down the pace of technological change.  New challenges are what draw many of us to engineering, but the pressure to constantly learn and re-learn can be a genuine stress.  It can be tempting to be complacent and to reassure oneself that one language and approach is all that is ever needed.

Aren't frameworks just groupthink? Why do I need them?

We have a cultural respect for individualism and suspicion against the wisdom of the mob - hence the joke that a million lemmings can't be wrong.  

However, applications don't represent a single thought or insight, nor even a whole book.  They are a collection of evolving thoughts that become machinery, and it's important that people can pick up the mental thread of the last contributor.  In more rigid languages, coders can end up so close in thought processes that they can complete each others blocks and patterns without thinking.  At the other end of the spectrum, JavaScript suggests so many approaches that it's more likely one finds two engineers ending up on the same chapter than on the same page.

So using a framework is always a good idea?

Just as the decision not to use a framework has it's complexities, so does the use of one, in particular the choice of framework. Some serious questions to ask yourself are:

• How widespread is this framework, and how widespread will it be?  A niche framework will likely mean your organization ends up picking up some of the bug-fixing, and can be as bad for siloing of knowledge as rolling your own solution from scratch.
• How tightly coupled will application code be to the framework? A great litmus test of your framework is what will happen if/when you later migrate to another framework.  Code migrations result in some amount of cutting away of "contaminated" code, and the flexibility and forethought of your chosen framework can have a huge impact on this.
• What would a home-grown solution look like?

In the Java world, doing something without frameworks still offers a wealth of community-learned approaches, in the form of JSRs (Java Specification Requests) - embodiments of some of the best practices drawn from years of framework evolution.  Even within Spring, probably the widest used server-side framework, following the use of JSRs is often encouraged over framework-specific code for a wide range of needs from dependency injection to things like ORM database mappings and job batching.

Some similar trends have come from the JavaScript world, with ECMAScript iterations absorbing features people once picked libraries for.  However the evolution of frameworks has been so much faster and more divergent in the client-side that there really aren't as many points of agreement.

In the end it has to be a weighing up of pros and cons - but when deciding to roll your own, keep in mind that every simple solution becomes more complex after a few months of feature changes.  Maybe your own team can find a neater solution than a large community has developed over time, but there's realistically a high chance that it won't.  However well it turns out, it will have less chance of outside support than even a marginally known framework.