Picking your (tech) poison wisely

What to do and what not to do when you consider adding new tools and technology to your tech stack.

Throughout the last couple of years, we’ve seen new frameworks, methods of work, and different ways of approaching problems come to our attention every week. And if you are in a position where you have a new project or have to migrate an existing one to something new, you have almost endless choices of approaches to any part of your tech stack.

Usually, at this point, you expect someone to tell you what you should do. But not me. Together, we will go through some of the things you absolutely shouldn’t do when picking anything new in your tech stack, be it the whole stack or any part of it.

Why do I want to consider anything new?

When moving your current project to the new technology or starting a new one, the easiest thing to do is just keep doing what you’ve always been doing and leave it at that. But is that always the right approach? This might be the perfect time to reconsider potential reasons for a switch. All of them can be valid for yourself or your team, although some might be more obvious than others.

The first one is simply legacy technology. If you have a current technology stack (or a part of it) with some stale elements, it might be a good idea to update it.

On the other side, the term “legacy” means something else for everyone, so what I am mostly thinking about is a framework or library that is deprecated and no longer supported.

When thinking about existing projects, they sometimes behave like a living organism. With constant evolution and growth over time, it is natural that project requirements change, and with that, a need may arise to change things up, replace existing paradigms, and introduce something new.

Something that is not talked about enough is the developer experience. Developers might not be satisfied with the current technology stack, which is enough reason to take the initiative and change the existing processes. Even though it sounds a bit simplistic, sometimes the only reason to change can be the fact that you would like to try something new. In that case, what’s stopping you?

Planning phase

Okay, you have decided that you want to change the technology stack in your project. Some things should be emphasized when planning such a change. For simplicity’s sake, I have decided to reduce the list to 5 important elements.

Establish project requirements, size, and scope
Understand what needs to be added (or changed)
(Re)evaluate the business logic
Define the current budget
Think about maintenance

Now, most of this advice seems like something that is common sense, and it is, but it is common sense we overlook very often. We usually like to enter a sort of “Yes we can” mode on some things. That is why it’s very important to establish clear scope and boundaries so we can hold the initial project completion to a sensible degree. Secondly, we have to check what needs to be changed. Sometimes, only a part of our stack would need to be changed. But if we have a pre-existing monolith application, it’s harder to find parts that will stay untouched.

If we have some pre-existing business logic, it should ideally be re-evaluated for multiple reasons. First, we have to consider that new technologies can make the process easier and simpler for everyone. Also, some decisions had to be made because the previous stack just couldn’t handle some requirements, which should be taken into account. But what is most important, you have to think about maintenance.

If you build projects that last, maintainability should be the focus for all stakeholders. Focus on creating as many rules as possible that are clear, simple, and above all, that have only one interpretation to avoid future doubts.

What (not) to do

Usually, when talking about solutions and ways to think, there is a lot of advice on what to do and how to behave. But here, we’ll be talking about what not to do, which should provide a different point of view and additional food for thought. We will cover five examples of the mistakes that engineers and engineering teams can make, but there are (as always) many more that could have been covered here.

Seeking complete solutions

Although it sounds a bit counter-intuitive, complete solutions are rarely the perfect fit for you. I like to call them “Jack of all trades and masters of none.” Usually, when searching for solutions like this, they often sound perfect and without fault, but after you scratch under the surface even a little bit, you can get bit by some issues you haven’t noticed when researching. The best way of tackling this is to look for features according to current requirements and future potential. Of course, looking at stacks as your jumping-off point is a very wise option, but you should not treat them or their creator’s ways as a gospel.

Immediately start looking for comparisons

Searching the internet for available options is the natural pathway to gaining information. But can there be too much information? Too many options? When searching for a perfect framework/library, you can get overwhelmed in a matter of seconds. Besides that, too many choices can make you overlook the correct one. To ensure better comparison, work your way so you can narrow down your choices to 2 or 3 that best fit your use cases. That will make it much easier to compare your choices in depth and help nip the decision paralysis in the bud.

Listening to hot takes

“That framework sucks!”
“People that do it in X way don’t know what they are doing”
“Trust me, bro”

Similar phrases can often be thrown in from various celebrities and influences, expressing their intense opinion of technology. It’s a very easy way to gather interest from people, but it is also a way for some people to fall into the trap of blindly trusting others. There can be many reasons why someone can dislike the tech, but they don’t always have to align with what you want to achieve. Every organization and person inside it has their preferences, so it is wise to check the claims from multiple sources to form as objective an opinion as possible. Or, the best-case scenario is to try it out yourself!

“But we’ve always been doing it this way”

The above-mentioned phrase is one of the most dangerous things to fall back on. It is not only a closed-minded way of looking at things but also a way of hindering progress and potential improvement. The first issue is that processes and how things work in one platform might not translate well to another. Secondly, failing to recognize and utilize this opportunity to rethink current processes can lead to issues further down the line and less successful migration. A big thing that should also be mentioned is as products grow, so do their issues and quirks, so you might as well take this time to address them and remove them from the picture.

Focusing only on the benefits

Focusing on the benefits is one of the most common mistakes engineers make in their pursuits of applicable technologies. When you think of it, it is very easy to find examples of positives, and when searching at a glance, they are the things most likely to surface. But, if you do a total 180 on this thinking and start looking at pitfalls and issues, it will give you a better overview of the limits of the system and a clearer image of whether you can be efficient within those limits.

By looking for weak spots, you will not only have a better fit for your project but also be more prepared for issues that may arise in the future.

Wrapping things up

Those and numerous examples show us how it is very easy to make mistakes when choosing a new technology or tech stack. If there is one thing missing from the above-mentioned list that I wanted to add, it is to not be afraid of making mistakes. Burdening yourself and taking things too harshly is never a healthy choice. Instead, focus on doing the best that you can do at the time and if you make mistakes, consider them a learning experience. After all, the advice mentioned throughout the article came from lessons learned from my or other’s mistakes.