The JavaScript ecosystem moves fast. Whenever you feel like you know something well, something new appears and seems to replace it. Many developers move from framework to framework to keep up with the latest way of doing things.
Obviously, we can’t do this when we are trying to build a team. We need to have some consistency in our tech stack. At the same time, you don’t want to be married to old technology if there are new and better ways to solve problems.
To solve this problem, here are some of the questions I ask myself and others before adopting new technology on my team.
🤔 Define the Problem
What problem are we trying to solve by adopting this technology?
❗Define the Risk
How certain are we that the problem would be solved by adopting this new technology?
Has this new technology been vetted by others? Can we point to people who have solved a similar problem to the one we face by adopting it?
🧡 Define the State of the Art
How could we solve the problem currently if we did not adopt this new technology?
⏳ Define Long Term Effects
Would this new technology replace the current technology, or is it additive?
What are some of the cons of this new technology? How would these cons impact us today? Do we foresee them impacting us in the future?
💪 Define the Effort
How much engineering time and resources would it take to move to this new technology?
Would people on the team need to be retrained? How much time would we spend using both, the current and the new technology, before moving to it completely?
Is there a way to start adopting it bit by bit, without blocking our current work?
📝 Write it down
Can we write the answers for all of this down somewhere?
By answering all of these and writing it down, we can usually make a good case of whether it makes sense to move to something new. Try it out!