How the YouVersion Web Team Evaluates New Technology
If you’ve been in the web development community for very long, you may have noticed that things move quickly. New platforms, new technology, and new ways of getting things done are coming out all the time. For myself, sometimes I feel like part of my job is just “keeping up with the industry”.
As someone who has been involved in web development for a long time, I have learned some “obvious” things that aren’t so obvious to folks that have more recently taken up the craft. One of those things is how to navigate all this movement and decide what investment is worth your time.
As part of our Digerati LXP program, we (Michael Martin and I) have had the privilege of having two incredible interns on the YouVersion Web team since around September 2018. In our time working with them, they asked some great questions that pushed our entire team forward. We were reminded to get out of our grooves and more talk about patterns and approaches that are ingrained in our workflow. In looking at our workflow, we were challenged to ask, “is this really the best approach?” (Because “obvious” never is!)
One of those questions was this:
With all the changes and new things happening in web development these days, how do you evaluate new technology? How do you decide what to use?
We had some great conversation, and realized we should write some of it down to share! So…here are some questions we ask when considering and evaluating new technology.
How It Fits
We heard about it. Someone mentioned it. It has a cool name. We click a link and read about it… So does it seem useful, fun, or interesting?
Does it appear to align with a way of thinking, or values that I have?
For instance, I have enjoyed Python, Javascript, and even PHP — (gasp!) — but I have yet to wrap my head around Ruby/Rails for daily use. It just hasn’t clicked (yet?) with the way I think about writing code, so it’s been hard to get into. That doesn’t mean it’s not an amazing and appropriate tool! I’ve just learned that I’ll be more productive with tools that match my way of thinking. And sometimes it’s extremely valuable to pick things up that challenge your comfort zone. So this may not get a lot of weight in the decision, but it’s definitely part of it.
Does it appear to save me time? Or is it just a different way of doing something I already do?
Some things are just different. Sometimes we try things just because they are fun! But when evaluating new tech for our production stack, we think a little more seriously about how it will make us more efficient.
I think Michael worded this question way better than I did:
Does it solve the specific problem we’re trying to solve in a novel or more efficient way?
It feels a bit obvious, but thinking it through: It’s going to cost us some time and effort to learn a new way to do something. Do we have the margin to learn something new? Will there be a return on our effort?
Whether we’re creating something new, or refactoring something that already exists… if something comes out that appears to solve a problem, we have to ask ourselves, is it also going to save us time, or be more efficient somehow? Now and in the future? Or would this “new shiny” thing just be a drop-in replacement for something we already know how to work with?
Will it require a total refactor, or can we replace/append this in small chunks?
Depending on the tech, some changes are definitely easier to implement than others.
Even something very useful might “cost” a great deal to implement because it impacts large parts of the codebase, and required a lot of refactoring. Whereas, something “new” but requiring only minor changes might be something we try sooner.
Longevity and Getting Help
If something appears to solve a problem in a way we’re interested in, the next concern is usually about the longevity of the new tech. How will we educate ourselves about it, and support it — or get support — for a long time?
First, are there already people on the team with experience using this new technology? Or, at least familiar with its concepts?
For example, if you’re choosing among front-end Javascript frameworks like React, Vue, and Angular and your team already has multiple people familiar with and enjoying Vue, it might have a little more weight for that decision.
Does it have a thriving, or growing, active community?
This one is pretty important. It won’t always apply perfectly to brand new technologies and frameworks, but it’s definitely something we consider.
Forums, documentation, and activity on Q&A sites like StackOverflow can be a great indicator. If we’re going to be using something for a long time, it’s ideal that a lot of other people are using it, and helping each other out. Projects with a large or active community are great because there’s more “surface area” for getting support than a sole maintainer somewhere who’s just trying to keep up.
Who is backing the technology? Will they be around for the long haul?
As part of the “longevity” facet, we will at least consider where a project came from, and if it appears like it will have continued support.
Depending on the project, it may be backed by a corporation or an organization of some kind. Keep in mind that great things also come from independent creators all the time!
Innovation
Sometimes new technology is very interesting but doesn’t have an obvious fit with our current production environment. Maybe it doesn’t directly solve a problem for us, but it seems like something we’d like to try.
Those things aren’t off the table! How else would we learn about things that move us from our comfort zone, or make us think in entirely new ways?
A question we ask in these scenarios is: “Is there a new or small project where I can “try it out” before making a larger commitment?”
Maybe there’s a small side-project that’s very low risk. For example, I’ve tried a few different front-end frameworks, or CSS libraries while working on small internal tools. These things were just a couple form fields and some server-side processing.
We certainly use margin in our workflow to try new things. Sometimes, just walking through the “getting started” section of documentation helps in our exploration of something new. Other times we explore new tech in low-risk areas.
Not every new tech has to go through the “should we use this in production?” filter!
Anything else?
There are countless more questions we could add or discuss, and probably some painfully “obvious” ones we’ll think of later. These were definitely the main points we hit while talking about this recently.
This subject was also covered a bit on a recent episode of the Syntax podcast. In the episode they talk about four questions to ask when considering new tech that are worth mentioning here:
- Is it better for the product?
- Is it better for the users?
- Is it better for the business?
- Is it better for the developer?
Do you have specific questions or filters for evaluating new tech in your life? We’d love to hear about it!
