How important are frameworks for Software Development

Not only in the Java world but in all the ecosystems of programming we have zillions of the framework which provide the notion that if that particular framework is used than applications will get done quickly. The marketing machinery works overtime to further these ideas. So is a framework answer to all the problems of the development. This is unfortunately very far from the truth. I am not saying that frameworks are not important. Let me say that, I do like frameworks and do use a lot of frameworks to do my job. In fact, given a problem statement, I do look around to figure out if some framework can do the job in a better way, rather me writing all the low-level stuff. A framework does bring a lot of advantages and important of them is to force the developers to follow industry-proven practices and patterns. Another important advantage I see with frameworks is that the popular frameworks carry with them a big community and strong knowledge base. At times there are example applications in the open domain to study. 
What I am trying to say here is to challenge the underlying notion that framework is the most important part in the software development process. Frameworks are seen as a panacea to all the issues. Especially popular with this notion are frameworks which can generate CRUD applications in a snap. But in reality, the real world starts after these CRUD applications. The CRUD applications are good to get a good feeling but the moment one tries to do something useful, it starts hitting into rocks and worse the generated code may actually hinder it in terms of understanding and fitting to a new set of situations.

In the software world, the easier question is how to do it. The more difficult and the important question is what to do? And the fact is that the development team tends to spend a lot of time debating and discussing the suitability of a framework over other. It's not that the debate is not useful, but the danger is to get into an endless loop in trying to achieve perfection. And the problem is that it becomes a self-defeating exercise. The team tends to debate on this aspect with the underlying notion that the time spent here will automatically translate in bringing more productivity and better application. And there lies the catch. The more time is spent on this debate, the harder it becomes to justify the value of the dollar spent. (To become a better developer, it's strongly recommended to align every action of yours to the impact it will bring on the balance sheet.)

So are frameworks not at all important? It's also not true. The choice of a framework will certainly impact you but the bigger impact comes from not understanding the requirements. Basically not understanding what we want to achieve.

So how much time to spend in choosing a framework. Some of the simple steps that can be taken to reach a quick decision.

• Build a time-bound plan in choosing the framework. The time may depend on the complexity, performance, and scalability of what you are trying to achieve. ( Be very clear that the decisions here are very important in terms of cost and time you are going to incur in future, but be careful about the "going round and round" ).

• Understand the present skills of your team. It's the people and not the frameworks who build software and write programs. Let me put it in a different way. It's the carpenter and not the chisel and saw who builds the furniture. Give a power saw to an electrician and ask him to make your dream wardrobe.

• Check which has a strong community around it at the moment.

• Check the licenses and dollars investments. Also while building the finance aspect, just don't count the visible upfront cost. Factors in the cost that might get incurred because of the research people will have to do in understanding and fixing things if the framework is in open space.

• Search in forums and web what people are saying about a certain set of frameworks. If not found anything useful, post a question in some of the neutral forums (Linkedin, StackOverflow, Quora) and see that how people react. until till the reactions become repetitive.

And let me repeat again. It's the people and not the frameworks who build software.

One more goal I try to strive for is to have as less number of frameworks as possible, in the application. The lesser the better. A lot of problems/bugs arise at those boundaries where integration happens. For ex,ample do not have fifty different javascript libraries. Don't introduce a new javascript library for every component.