When it comes to IT, there are different mindsets — the conservatives, the hipsters, the pioneers — and everyday a new technology is released, trying to solve a problem in a better way, or from a different perspective.
Before, our world was made by only a handful of programming languages, with a small set of tools and frameworks that would fit in our environments. Today, there's a bunch of them. And instead of helping, having that many options sometimes end up getting us blocked.
With time, I learned that there are some particularities that can favor — or have the opposite impact — in my acceptance of a new technology, according to the context I am in. And as part of my process of learning, I would love to share it in the form of questions as a way of refining this knowledge.
The questions are:
- Is it open source?
This, for me, is the only deal breaker. I promise you I will try not to give you a bias in the other ones, but proprietary technologies usually take more time to launch releases, and usually do not share learning materials freely.
As a developer, I think it makes a lot of sense to be part of the teams that upgrade the tools I use, specially if there is something I want to do with it that is still not supported. Also, being able to read the source code usually gives me a better understanding of the tool as a whole.
- How new is this technology?
There is actually a lot of information behind this simple question. In software development, there are always a lot of different ways to solve a problem, and a bunch of technologies that would help you in the process. Ruby or Go? JMeter or Gatling? Minitest or RSpec?
The idea is that tech evolves, and we learn from our mistakes. Everything that is new has the purpose of solving a problem from a new perspective, or in a better way; this does not mean that it is better for your problem, or for every problem.
But being new also brings you the opportunity to collaborate with its evolution — and also to find bugs in its development. Which option brings more value to your team?
You can be on the top of the technology trends, or you can end up having to choose a new tool if it is discontinued. Is it worth the risk?
- How many open issues are there today?
If there's a new technology with a number of problems and defects already reported that are not yet solved, this may mean that it doesn't have very active members, or that it is being discontinued in favor of something newer and shinier.
You can see this as an opportunity to actively collaborate with something you really believe in, or as a strong signal that you should find the nearest life jacket to jump from this sinking boat.
- How frequent are its releases?
The frequency on which new releases are launched is also a pointer of how active the community around the technology is, and how fast its problems are found and solved. Sometimes, older and more consolidated tools have a slower release cycle, since there are not that many critical bugs to be fixed, but this can also mean that the specific feature you need and is not supported yet can take a while to be implemented.
- How big is its community?
How many contributors does the source have? How many stars, forks and watches on GitHub? It seems like such superficial metrics, but they can show how open to contributions the tool is.
The bigger the community, the bigger the support you will have in learning to use the technology, having your questions answered and the bigger the chance of having any problems you go through documented in the technology page itself or in sites like stack overflow.
- How complex is it to prepare the environment for using the technology?
To some projects, this is critical information. If you have the need of only choosing plug-and-play technologies and you don't have time to spare configuring it, a way too complex and personalized tool may not be the best option for you.
- How complex is it to do a simple example?
There are technologies that, believe me, you need to read the whole documentation and watch online courses before using them, even in the most basic form.
Maybe it is worth the effort, if the technology solves a critical problem you have, but the simpler it is to use something new to get the practical experience from it, the best.
Note that complexity is something that depends on the context. To someone comfortable with Java, for example, using new technology that implements tests in other programming language can make it complex.
- How hard it is to integrate the new technology in a CI?
I don't know if this is something you care about, but for me, automating tasks that can be automated is always something that is worth to evaluate.
- How good is the feedback the technology gives you?
If you could not understand me one hundred percent in this one, it is fine. I wanted to be really generic.
When we're talking about a testing tool, for example, I would like to know if the reports it generates are simple and to the point, or if it just executes without giving me any feedback.
If it's a provisioning tool, I'd like to know if it was able to run successfully or why it failed.
- What makes this technology special?
Usually what makes new tech known is its ability to solve a new problem, or a problem already solved, but with a different perspective, or in an easier way.
Maybe it's still something hard to use, but that brings something really new, or that makes a lot of sense in your context.
Which are the most important things that you think about when choosing a new technology or tool to add to your project, or to start learning? Was this list helpful in any way? Do you disagree with any of the points listed here?