What to watch for in a Framework
Frameworks are created to make our lives simpler. They try to hide most of the complexity from an environment using layers of library code. In that way, users don’t need to worry about managing the lower level features of the environment. They should, instead, concentrate on the higher level functions (business logic) of their code.
With the increasing number of technologies that we have around us, there has also been an increase in the number of Frameworks — all of them trying to compete for attention.
In many cases, frameworks do a good job of hiding low level information from programmers. However, they also have a few problems of their own.
For example, when using a framework we are hiding some complexity, but also creating some additional levels of complexity that can become a major issue.
For example, consider web frameworks. There are hundreds to chose from (literally), but most of them are equivalent. They solve the issue of letting programmers create a web site quickly, by taking care of basic mechanisms, such as serving web content and accessing a relational database.
However, web frameworks also create its own particular language, that needs to be understood by developers before anything gets done. Also, although they make it easy to create simple websites, things may get complicated when less common features are required from the web site.
In the end, power users need to spends lots of time learning the ins and outs of a web framework. A high level of proficiency is necessary to achieve more complicated results.
In some extreme cases, the framework may get in the way between you and the intended result. This is where things stop being fun and become a nightmare.
To avoid such problems, there is a number of things that I consider before using a Framework:
Documentation: if you have to mess up with a framework, it needs at least to be well document. There is nothing more frustrating than trying to get something done and having no clue of how it can be achieved.
Reading the source code may sometimes be a solution, but it only works if you know what the source code is supposed to be doing. If you don’t know this, having the source code is not of great help.
Ability to reach for the lower level: what happens when you want something that has not been implemented in the framework? A possible solution is to reach for the lower level if that is necessary. Don’t use a framework that makes this very difficult. Sooner or later you will need additional functionality.
Extensibility: even though a framework may strive for completeness, there is always some feature that has not been suitably covered by its creators. In that situation, is it easier to extend what has been provided, or you have to start from scratch?
Availability: how many people are using this framework? A lot of users probably means that you will have a better time getting support. It will also be easier to find someone else to share experiences, or even use your expertise in somebody else’s projects.
Answering these questions may turn your decision to use a framework much easier. After all, if you do anything, don’t start using a framework just because it looks cool or it is easy to achieve some specific effect — the decision of what framework to use must be better informed, because it can deeply impact the future of your project.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
