With a vast choice of technology, there is always a question of how you will pick the tech stack for your next venture. Would you go with a bleeding-edge tech released last year, or would you go with something that has been around for decades?
There is no straightforward answer, but to elaborate more on the topic, we talked with fellow AOByters to determine the decisive factors when picking technology for the project. We will also present why these points matter and how they define the projects’ tech direction.
Continue reading to learn what Karen, Tigran, Stepan, and Davit emphasize about tech stack choice for projects.
When picking technology for our project, we look at popularity and maturity. Indeed, any technology can have bugs and plenty of room for improvement. The point is whether the technology is popular enough to have a big community that can discover and solve bugs efficiently.
It is also essential to estimate how big the community is to reach out to them whenever we are stuck at some point. We also consider whether the tech gets actively developed or whether it has been a while since the community has seen a new release. These are points to address when thinking of how maturity and popularity may affect the choice of tech stack.
Maturity is the framework’s popularity multiplied by the time it has been around. Therefore, the maturity of the technology implies that it has been around for a long time and has been popular, meaning it has been tested and fixed by the community.
The important takeaway is that it is hard to overlook popularity. It could be dangerous to pick technology with a small community or not actively developed.
Maturity is more arguable: some mature technologies have solutions that are fundamentally inefficient these days, and it is more beneficial to switch to a newer one, which while less mature, has a fundamentally better way of solving the problem.
The team’s skillset is yet another point that needs to be taken into account when picking the technology. Of course, you want your team to be experienced in the tech stack that will be used to develop the project. If you have an experienced team in the suggested tech stack, it is a no-brainer from a “Team Skills” point of view.
Now, what if you don’t? What if not all the team members are experienced in the tech stack? Having a team, which is, by and large, inexperienced in the tech stack that has been picked, can lead to a disastrous result and should be avoided.
What if you have some people on a team who are experienced in the tech stack and others who are not? Switching between technologies is not alien to a lot of tech people, so there should be a way to find a healthy balance. For example, suppose you have a team leader experienced in the tech stack. In that case, they can successfully support two other team members who are inexperienced in the technology but have experience in a similar tech stack. The 1:2 ratio is a safe way to go forward here.
The takeaway is that if you have an experienced team, it’s a no-brainer. A 1:2 ratio of experienced people and people experienced in a similar technology is an excellent way to move forward.
Yet the maturity of the technology and the team’s skillset are essential points. However, the most critical question is which technology allows us to solve the problem we are trying to tackle efficiently.
A checklist is a simple yet very powerful tool in such cases. To generate a checklist for the technology, first try to think of the core features of your software. Pretty much any system you can think of will have features such as authentication, user management, reporting, etc., but those are not core features of your software.
You need to ensure that chosen technology allows you to solve core problems efficiently. Maybe your system’s core functionality requires a lot of scrapping, or perhaps you are going to do heavy image processing. Put these requirements at the top of your list. Now think of all the features your software should have and generate a list of the requirements based on those. Here is an example of a simple checklist.
Evaluate the technologies based on the requirements you have listed. You can assign weights to each of the points in the list. The items related to the core features should have a higher weight. See which technology scores the highest.
The key takeaway is – when choosing a technology, it is essential to understand the core problem that needs to be solved and assess technologies accordingly. A checklist is a simple yet very powerful technique.
Last but not least – the legacy code. If there is a legacy code, we have to answer whether we will keep the legacy code or start implementing the software from scratch.
Ideally, to continue with legacy code, you want well-documented and clearly written code. But let’s be honest, that’s rarely the case. Even with a non-ideal codebase, there are a lot of arguments for continuing with legacy code – first of all, budget and timeline. Creating software from scratch requires considerable financial resources and time. If the team adopts the legacy code, it might cause an exhausting learning curve.
There are still cases when you can conclude that abandoning legacy code is the way to go, maybe because the existing code cannot efficiently incorporate new features or the code itself is virtually unmaintainable. In such cases, still think of the possibility of adopting a hybrid approach. Maybe you can keep a legacy code yet have the new features implemented as a separate microservice using other technologies, or perhaps have a legacy code wrapped as a new software module?
The key takeaway: Throwing away a legacy code is a very serious decision, as the costs of developing software from scratch are usually very high. Unless the existing legacy code in no way corresponds to the new requirements, it is probably a good idea to keep the legacy code. If you conclude not to continue with the legacy code, it is still worth entertaining the idea of wrapping or creating new addition using new technology. Re-writing the entire software from scratch should be your last resort, no matter how attractive it may sound.
CEO at AOByte
Software Developer at AOByte
Software Developer at AOByte
Software Developer at AOByte
Interested in the insurance software development solutions AOByte provides?
Send us a message, and we will get back to you to discuss your goals and project scope.
Input your search keywords and press Enter.
