Choosing your next framework

In one of my previous articles I described the difference between strategy and tactics in software development. In this post I want to describe, what can go wrong, if you focus on tactics and ignore the overall strategy. Lets take a situation I have seen at many companies: a new project is born and some people can create something from scratch. Most of the times this means that technology decisions that have been made before, can be questioned and the new scope maybe allows to try out something new. Maybe something that is easier to use or faster to setup. This can have both positive and negative consequences:

On the positive side, this approach could lead to increased productivity and faster development times. If the new technology allows you to work more efficiently and effectively, it may be easier for you to deliver features and functionality quickly, which can be a significant benefit for the organization. Additionally, by exploring new technologies and frameworks, you may bring fresh ideas and perspectives to the project, which can contribute to innovation and improve the overall quality of the software. I love exploring new languages and frameworks because they help me to get a new view on some problems and learning the concepts here makes me a better developer.

However, there are also potential negative consequences of this approach. Firstly, if you choose to use a different technology from the rest of your company, it could create a fragmentation of knowledge and skills within the organization. This could lead to communication problems, knowledge silos, and even conflicts between team members who may have different ideas and opinions on which framework is better. Additionally, it may also result in additional costs for the company to maintain multiple frameworks and provide support for different development teams.

Secondly, if you choose a new framework without involving the rest of the team, you may be creating additional technical debt. Technical debt is the cost of fixing or reworking code in the future due to shortcuts taken during development. If you choose a new framework without considering the long-term implications or how it fits into the larger technical architecture of the company, you may end up creating technical debt that will need to be addressed later.

Finally, you have to learn it. There will be new challenges that come with the new technology and maybe easy solutions that worked before, will not. So, somehow you start from scratch, which can be a cool experience, but it can be some hard work, too. Please keep in mind that not only you have to do it, everybody in your team or company needs to learn it. This can be a great opportunity to work together, or super frustrating for your colleagues and maybe even your company if feature development slows down.

In summary, while exploring new technologies and frameworks can lead to innovation and productivity gains, it is important to consider the implications of choosing a different technology from the rest of the team. To avoid potential negative consequences, it may be beneficial to involve the rest of the team in the decision-making process, evaluate the long-term implications, and ensure that the chosen technology fits into the overall technical architecture of the company.

My best experience with the introduction of new technologies has been when they have been supported by as many people as possible. Ideally, there are some colleagues in the team or the company who are happy to get to grips with something new and then actively support the decision, even if there are problems at the beginning.