Adopting Technologies
Tags: devops, maintainability, tooling, workflow
Published: 2022-12-17 15:36:30

When thinking about and testing new and exciting technologies, teams can often get overwhelmed with the thoughts of what to test. or what should be important to us even before testing or considering a tool, framework, or platform we might want to add to our tech stack.

Here is a curated list of some of the key features I look into when learning and considering using tech in my personal projects or at work with the teams I work with.

## Activity & Community

One of the first and more noticeable things to look for when checking out new tech is the community and activity of the project, an active community can serve you well at the start and further down the road.

It could be helpful even when reading into the tool you’re using with more articles or documentation being written or when getting stuck and in need of help, someone might just be stuck with you, and even better - someone might have already got a solution to your problem!

Some things to look for are:

 - Stars on GitHub ⭐
 - Is the project “mature”? (how long has it been in use/development)
 - Active Users
 - Issues & PRs
 - A slack/discord/platform of the community

## Project Size

When looking to get a job done you might want some ready-made software to already do your job for you, and that’s great! so you can start and get your hands dirty with the real challenge.

That is indeed a very good way to not repeat others’ work, but when doing so it’s important to remember you’re also introducing yourself to someone else’s code, someone you might not be familiar with and someone you might not be able to rely on for long.

That puts us in a position where the size of the project really matters.

If we’re looking at a complex project fixing a slight problem, we might be better off just implementing it ourselves, but if we are looking at a more challenging chore, considering using a project even if it’s a bit large, it can prove to be very practical and save us a lot of time in the end.

## Maintenance

As we just mentioned while talking about the project size and activity, maintenance is very important, we want to be sure we can rely on the projects we use.

OpenSource projects don’t have a strict responsibility when it comes to maintenance, and when we don’t have active maintenance this metric becomes far more concerning, someday we might hear that our favorite CI/CD platform isn’t going to be maintained anymore, or even our central go framework which we based our whole application on will stop being maintained.

Some tools have active support, and they might even have the founder/owner of the project actively responding to PRs, and Issues.

While a strong community can really boost your whole workflow and process, support from the maker of the tool might be needed in some obscure use cases, it’s essential to rely on software that is actively being maintained, and so even without intimate support from the owner, the maintenance might be just enough, and we need to keep in mind that in the future the project might have a different owner and even from the active community.

Something important to keep in mind is that after we choose our technology we still need to actively watch out for updates and maintenance changes.

## Programming Language

The last but certainly not least bullet point is the programming language being used and supported by the project.

Sometimes we might just be using a project as an outside service and sometimes as a fully integrated library or SDK.

We need to check that the main languages that we use are being supported and it’s even better if the project itself is written in one of them, then when experiencing problems or looking at Issues some of our team might be able to help fix them and submit a PR.

This metric isn’t as groundbreaking but can definitely serve you well, as I can say from my experience it has.

## Summary

We want to be aware when using someone else’s code and looking at new tech, we want to know we aren’t just inviting problems into our workflow and tech stack and we want to follow some rules in doing so. I hope now you can be a little bit more sure about when integrating new technologies into your tech stack.

---

Originally published at [https://itamadev.com](https://itamadev.com/posts/20221126-adopting-tech/) on November 26, 2022.