Use frameworks or not
Guided development vs flexibility
One of the most frequently asked questions a development team faces when starting a new product or project is what architecture and technologies they build it with. It is a question whose answer can mark the success or failure in the mid and long term of a project. Knowing what to look out for and making the decision in an informed way is essential.
What options do we have? 📦
When it comes to building a new service or application, we have different options available:
- Use a framework: Provides us with a comprehensive and opinionated structure and applies a specific architecture and workflow. Developers work within the constraints of the framework and adapt to their way of doing things. Examples include Spring, Angular, Ruby on Rails, Django, or .NET.
- Use a set of libraries: A collection of reusable code functions or modules that can be integrated as needed, without dictating the overall structure of the application. For example, it would be to set up an API using one library to create web servers such as Express.js, Flask or Sinatra and using another to have a database persistence layer such as Prisma, SQLAlchemy or ActiveRecord (used outside of Rails). But we set up the structure and integration between the different layers ourselves.
As I often like to remind, all of these options are tools we have at our disposal and you need to know when to use them. They all have advantages and disadvantages and you have to take them into account to make the best decision.
Referring to the book Software Architecture in Practice, in a section that comments on what can be considered “good” architecture, it reveals that software architectures are evaluable, but that evaluation only makes sense in the specific context that surrounds it.
This clearly indicates that the objective of our development and the conditions in which we carry it out must mark the architecture and the tools we use.
What to keep in mind 🔎
Therefore, understanding the context surrounding our product is essential to making the decision.
Among the things that can influence whether you choose a specific framework or set of libraries are:
- The time we have: sometimes limited by the hours we have available for development or by the time-to-market. It’s the effective time we have for the new software to end up in production.
- The team we have: the people who will carry out the development. Their background, their seniority and their previous experiences.
- The purpose of our software: what needs our software is covering, its nature (it can be more or less technical) and whether it is a one-off or a product that will continue to grow.
The time we have ⏰
Software development is often limited by the time we have to dedicate to it. So much so that the vast majority of the industry (at least half of which is dedicated to consulting) charges directly for the hours invested.
And it’s an important aspect to keep in mind when choosing which technology to use to develop a system. Which takes less time, frameworks or libraries?
Well, it depends.
It depends on what we are developing, the experience that the team has with the different tools (more on this below) and the advanced work you have as a company (in the form of things that you have already done and can reuse).
As a general rule and for simple products (CRUD or early MVPs) it is usually assumed that the use of frameworks leads to faster developments. However, in the mid term it can be limiting since we are coupled to a way of doing things and it may be in the way when it comes to iterating the product.
The team we have 👥
Another important point (and which is also related to the time we invest) is to consider the team we have.
In terms of their previous experience: if your team’s day-to-day work is to develop with a framework, it may make more sense to do it with the same framework. In this case, strategically investing in training in other technologies can expand the range of options you have when making these types of decisions.
In terms of seniority: normally frameworks offer a more guided development that benefits more junior profiles by offering more stability and ways of doing things. On the other hand, the use of libraries benefits more senior profiles who are able to adapt the application with the best possible structure to solve the problem at hand.
Frameworks can help compensate for the lack of specialized knowledge or experience within the team by providing well-tested and documented solutions to common development challenges, which benefits a more junior team. However, many times trying to force a framework to adapt to a specific problem can lead to lower software quality.
The purpose of our software 🚀
The purpose of our software is also important to consider when choosing the tools with which we will develop.
It is not the same to develop a static product that is not going to change in the short or mid term as it is to build software that will not stop iterating.
On the other hand, the technical nature of the product itself is also decisive. Creating a simple e-commerce to sell products from a local store is very different from building a SaaS to manage customer emails. Depending on the technical complexity of the product and how solved the problem is already in the community, one thing or the other may make more sense.
Therefore, if we are going to build software that is going to be in continuous iteration or that has a high technical complexity component, it is more advisable to use libraries since coupling to a framework can bring problems in the mid term.
On the contrary, if we are going to build a simple product that has already been solved by others many times or that will not require much change, we can choose to use a framework.
A middle ground 🤝
The use of libraries is my go-to recommendation in most situations. Although in cases where we have a fairly junior team or where our product is simple and not going to change (or is disposable), a framework can make sense.
However, there is a middle ground that I like to recommend for these cases which is the use of boilerplates. They are a set of files and source code that serve as a starting point or template for a new software project. It’s a basic, predefined structure that provides the initial setup and some common functionalities needed to start developing an application.
Building a boilerplate with the libraries we usually use and a recommended structure can replace the benefits that frameworks give us with the advantages and freedoms that libraries provide.
TL;DR
The choice between using frameworks or a set of libraries is a crucial decision that must be made considering several factors. It is essential to understand the context in which the project is located, including the time available, the development team, and the purpose of the software. While frameworks can offer a comprehensive structure and speed up the development process, they can also limit long-term flexibility. On the other hand, libraries allow for greater adaptability and control, but they may require more expertise and effort to integrate correctly.
In most cases, using libraries in conjunction with creating a custom boilerplate can offer an optimal balance between efficiency and flexibility, providing a solid foundation for scalable and quality software development. Ultimately, the choice between frameworks and libraries depends on the specific needs of the project and the development team, and should be carefully evaluated to ensure the long-term success of the product.