It’s quite easy to become overwhelmed when it comes to picking the right technology. There are a number of criteria that we should pay attention to really evaluate which option will work best for us. You can imagine the stress of any new developer if they are trying to learn a framework. Look at how many different JavaScript frameworks that exist that do similar things and this just with JavaScript which doesn’t include frameworks in other programming languages. To make that search easier here are a few things to considering when evaluating software technologies to use on your next project.
Standards and project ecosystem
Does the project adhere to best practices and well-known standards? If so, it’s much easier for you and your team to integrate a technology that follows the expected protocols. Does it support other tools and libraries that can make work a lot easier to perform? Is anybody else on your team familiar with the technology. If you should stumble on an issue that you can’t solve will you be able to gain the support from your coworkers around you?
Project age and maturity
You want to determine how established the project you’re considering. How many releases have they gone through? The idea would be any technology that is far along in their releases means they would have had enough time to correct and improve the platform. The fewer bugs you can expect the better off you will be.
How much weight you give to the criteria is determined by the role the technology should play in the overall project. For eg. I wouldn’t be so quick to jump to a brand new database technology that promises to perform miracles over a much more mature database.
Maintainership
This works alongside the maturity of the technology. Coupled with how mature the technology is we should look at how well it is maintained. You want to know that the support for the technology is provided by a wider community. The bigger the support the more you can expect a stable platform and quick responses to fix any issues that might have been discovered later on.
Release velocity and stability
Another, a factor we can look at is how often updates are released. You often want these updates to happen in quicker intervals. Waiting for months/years for a fix can be daunting. When releases happen, can you easily determined what happened? Is there a lot of breaking changes each time an update is done. Think about it, each time a technology is updated you would have changed a few lines of code before you can fully use any new update that would have come with it.
Documentation
Nothing beats good documentation. Documentation is a basic requirement for any project. Amean, how on earth would you figure out how to use all the APIs or integrate it with your project, read the source code, umm no thank you. For one, documentation should exist, it should be discoverable, it should be searchable and it should be up to date with the current release of the project. I have had experience trying to learn platforms that their documentation didn’t match up and you would imagine the frustration that causes when you’re doing exactly what was written but it still didn’t work. Wanna waste a developers time, give them a poorly written documentation.
Final thoughts
The options presented doesn’t necessarily include an exhaustive list of what to consider. I implore you to choose the ones that make the most sense for your project and scenario. The number of choices at your disposal can be intimidating at times. Hopefully, you can use the above criteria better enable you to determine the right technology for your needs.
