There are a dizzying array of technology choices out there. Need a message queue? Do you use Kafka, RabbitMQ, or Redis (just to name a few). How about a data store? Maybe MySQL? Postgres? One of the plethora of NoSQL offerings out there? How do you choose the right technology?  This is a question I’ve faced many times in my career. I’ve found that if you break the problem down into three main steps, you’ll usually make the right choice.

What’s the Problem?

Before heading off in the pursuit of shiny new technologies, take a minute to think about what you’re trying to accomplish. Write down a list of the problems you’re hoping to solve. It’s hard to evaluate any technology if you don’t have an objective set of criteria to compare it against. Think about some of the following questions as you make your list:

• Is this a one-off project or something that will be used across the development organization?
• Who is the intended user of the new technology? QA? Developers?
• What is the skill set of the people who will use the technology?
• Who will maintain the software? Who will upgrade it and make sure it’s still working?

Build a Feature Matrix

Once you know what you’re trying to accomplish, the next step is to translate that into a set of features you can use to evaluate each product. This feature matrix is built as a table where each row in the represents a feature you care about and each column represents how a particular product satisfies that need.

For now, just fill out the features you think you need and the initial list of candidate technologies to evaluate. Don’t be overly concerned about making it complete at this point. As you begin to research, additional features and technologies will come to mind and can be added as you go along.

Research Candidates

Now it’s time to go shopping! Start reading about each technology you’ve initially identified and fill out each column in your feature matrix. For each feature in your list try to figure out how each technology satisfies that feature. Sometimes the answer will be right in the documentation. Other times you may have to dig into the source code or even play with the technology to get an answer.

In some cases, each table cell will simply be a yes or no answer. Does the product have the feature or not. However, it’s more useful to provide additional notes. For example, if one of the criteria you’re interested in is stability, you might make notes about when the project was started, how often releases are made, if there’s an active user community, who else is using it, etc. A particular technology might satisfy one of the criteria, but if it’s extremely convoluted to use or needs an extra integration to make it work, make a note of that.

As an example, if you were attempting to choose a messaging provider, a feature comparison matrix might look something like this:

Go With Your Gut

By the time you’ve finished filling out your table of features, you should have a pretty good feel about which technology you’d like to use. Go with that instinct. More often than not, it’s the right choice. The feature matrix was mainly there as a framework to help you make an informed choice.

Of course, your manager and co-workers will need to hear something more than “it feels like the right solution”. The notes you’ve made along the way can be used to make the case to the others in your organization. This is an important consideration if you want the solution to be widely adopted.

Conclusion

Selecting a new technology can feel like an overwhelming decision. Treat it like any other engineering problem. Break it down into small, bite size steps, define objective criteria and meticulously work through each item. At the end of the process, you’ll have a good deal of data to reference as you make a decision about which technology to move forward with. Take this data, follow your instincts, and you’ll choose the right technology.