In my day-to-day as a software consultant at Stride, I often help evaluate new technologies (i.e. framework, library, language). Over time, I noticed certain questions and thoughts continuing to come up, like how’s the community around this technology? How many people are using it? Is it easy to learn? And so forth.
In an effort to give voice to the subtle feelings, the small questions, and small thoughts that may come up when you’re researching, here’s my checklist for evaluating new technologies:
Usage
It is important for a technology to have an engaged community or a strong interest in a community. There are several ways to measure this:
- Package downloads in a given month: Some package managers, like npm, give statistics on how many downloads a package will have over time. Anywhere in the thousands is good. For example, React and RxJS have ~1 million downloads per month.
- Github stars and forks: Another measure of usage and peer engagement.
- Amount of pull requests and their acceptance rate: Is the project actively being developed and improved? It’s also important to gauge how the maintainers regard changes. That will affect contribution and, by extension, adoption.
- Amount of open issues: How many there are and what severity. This will give you a sense of how ready the project is (see also: production worthiness). It is also important to gauge maintainer quality. Are they helpful and open, or closed and prickly? The project won’t get far with bad contributors.
- Social media engagement: People are tweeting and writing blog posts about this tech. Their tone would be one of excitement or intrigue. Others may write about how they are adopting the new tech.
Technical advantages
- The technology has improved upon current offerings.
- The same problem cannot or should not be solved with an existing or more established piece of technology.
Design
- The project’s documentation is clearly written and thorough.
- The project has a clear and sensible roadmap.
- You will write less or better code with this technology.
- This technology aligns with the language or framework it is intended to be used with (See: their philosophies and design goals).
- Source code must be well tested.
Community engagement
- You could convince someone with no experience in this particular tech stack on this technology choice (e.g., a seasoned ruby developer on webpack).
- This technology is exciting in some way.
Integration
- If the technology integrates into another system, the two roadmaps and philosophies align.
- There is an escape hatch in case this technology does not work (e.g., rendering HTML from React components).
- The design allows for loose coupling, so you can swap another implementation in easily (e.g., implementing your own flux architecture after using a library).
- It is stable enough to use in production.
- This technology does not require a lot of churn (See: early versions of React).
- There is an ecosystem surrounding this technology.
Extended usage
- Besides its intended usage, the technology could be adopted in a different setting (e.g., Redux in server-side apps).
- You can see yourself working with this technology in one week, one month, and possibly in one to five years.
Project adoption
- You could convince a team or another developer to change to this technology.
- This technology would be useful for a range of projects.
- It is easy to adopt into an existing project.
- It is easy for a junior to learn.
- You could introduce this to a skeptical team in isolated pieces (See also: escape hatch).
If you are interested in using some new technologies for your business but don't know where to start? Our team of Agile technologists can help you implement the right technology for your business. Contact us today to learn more.
Ian McNally
