Use technologies and frameworks that you know
“Use technologies and frameworks that you know” is one of my values in Practices to rapidly ship new software products as an engineer.
Engineers love to learn. We love to explore new ideas and tools that we haven’t encountered before. However, that desire to learn can be a pitfall with all of the new technologies, frameworks, and tools being released.
If you visit Hacker News this very moment, you can probably read about multiple new technologies that you haven’t used before that sound amazing. Open source is great, but there’s a new popular library or framework every week.
Concerns I have with new technologies
What’s the learning curve? There is little to no learning curve with technologies you already know. That is an immediate advantage. Even if the learning curve for the new technology is relatively simple, you’ll still find yourself looking up syntax or reading the docs for simple things.
You’re likely to implement bad patterns. I’ve seen engineers shift from one technology to another and use disastrous patterns that don’t work in the new technology. The pain often isn’t seen until it’s too late to turn back. If you know your technology well, then you already know the right patterns.
Documentation may not be great. Documentation is time consuming to write and maintain. Even for huge companies with widely used APIs. It’s even more scarce for newer technologies, where the creators have not had the time to invest in docs yet. Frequently the only accurate documentation is the source code itself.
Community support. How big is the community around the technology. Are there other real companies out there using this technology extensively yet? Are you going to be able to find blog posts and relevant information on it with Google or Stack Overflow searches? Is this just the flavor of the month? Or is it here to stay?
How many contributors are there? Without enough contributors, there is a risk of the technology becoming stale when the core contributor takes a break from engineering or no longer needs the technology at their new job. If only one person is running the show, you’re entirely dependent on them. For example, I opened a bug fix to a React Native library. It took a full year to get merged, but by that time I’d already spent the energy to switch to a different library. I created Should I use this package as a quick gauge for npm packages.
There are likely a number of basic bugs. Even something like React Native, which had huge support seemed to miss some basic stuff. Once when adding a new component, they missed a basic fence case (someArray[someArray.length] vs someArray[someArray.length — 1]). When you reached the bottom of the list, the app crashed. The fence case is a basic concept, but somehow gets missed in the release of a massive library.
You don’t know how it will work at a larger scale. Will it scale from a performance perspective? Will it scale for collaborating with other team members? What happens when your product needs to become more complex? Will it be easy to implement that additional complexity, or is it difficult to do anything besides the basic use cases in the tutorial examples?
Does it contain all the basic functionality that you expect and will need? Or will you end up re-writing the wheel? One of my favorite things about Python is there’s a single community consensus library for almost everything. There’s a lot of community support behind that one library and it will likely have all the basic functionality you expect.
Are there standards in place? Sometimes things that are easily foreseeable lack any standards or have frequently shifting standards. Something that comes to mind was the lack of standard error handling patterns in GraphQL, which resulted in lengthy discussions at my current company costing a lot of engineers’ time. Errors should be an expectation in any sort of request/response. HTTP codes have existed as a long time at this point, so why are we having to reface the same problem?
When should I use a new technology?
If you’re working on a hackathon project, or the main goal is to learn about that new technology, then great! These are good opportunities to figure out how you like something and what the advantages and downsides are. Tangibly working with it helps learn a lot more than just reading about it.
If there are significant advantages you gain from the new technology, then go for it! An example of this was when I was at NerdWallet where we were asked to build and release a mobile app for both iOS and Android within 5 weeks. None of us were particularly strong native developers, but we had React expertise and some existing libraries from our web app. React Native, which was still in beta granted us the velocity to hit this deadline.