This time, our post will be relatively short. Recently, we have encountered an opinion that when developing software, it is best to use only the most popular frameworks. The criteria for popularity were to be: the number of applications in projects, the number of downloads directly from VCS statistics, and the frequency of updates. As you might guess, such a radical opinion has its basis, usually in the experience of individuals. But is it justified? We will try to answer this question in this post.
At the outset, it is worth considering where this opinion comes from. We have identified two primary sources for this perspective on the frameworks, libraries, and tools used. The first is simply professional experience and familiarity with a given technology. If a professional has been using a specific solution for years, it is logical that he will perform the same task faster and often more accurately than when using a new library that he has to familiarize himself with. Project time plays an important role here. A programmer, dev ops, tester, or other member of the team often cannot perform the assigned task perfectly because it conflicts with business objectives. As a result, instead of choosing a framework that was created to address a specific niche, the choice usually falls on a solution which the team feels comfortable with, ignoring the hidden costs, which will be discussed later on.
The second situation in which a dedicated solution is rejected is aversion, often caused by personal resentment towards a given technology. This is not an unusual phenomenon, as promising libraries dedicated to solving a specific problem often lack documentation or, worse, the existing documentation is incorrect – when going through its steps, the employee is unable to bring the software to a stable, working state. Less often, this reluctance stems from a lack of competence, but that is not the subject of today’s post.
But getting back to the point, the statement that it is best to use the most popular libraries is partly true. These provide frequent updates and offer better support. However, in terms of scale, the issue of software architecture seems much more important. It is not without reason that there are relational, graph, and other databases, as well as frameworks that support them. Of course, it is possible to model a fraud detection system using relational databases, but in this case, graph databases offer much greater efficiency. Additionally, at a certain stage (scale), the use of relational database systems is no longer possible.
Therefore, the chosen architecture of solutions and a framework tailored to it are much more important than its popularity. We can conclude that this radical view is therefore very populist and dangerous. The second feature is related to the hidden costs we mentioned earlier in this post. A seemingly cheap and quick solution that suits the entire team may reach a stage where its further expansion is unprofitable or even physically impossible without rebuilding the architecture. A popular relational database, one of the highest-rated programming languages according to TIOBE, zero stress, challenges, and problems—unfortunately, such a utopia usually ends with a wall, where the customer is left with an application tailored to his needs – without the possibility of expansion, and the entire project (except for maintenance) ceases to have a raison d’être.
We pay special attention to this and urge you to first consider the potential for expanding the solution and its architecture, and only then the popularity of the frameworks used. We understand that sometimes a project must be completed, and there is no budget for the solution we have mentioned. However, it is important to be aware that in this situation, future cooperation may prove impossible, and as the scale increases, the client may begin to raise concerns.
