Questions for evaluating a new technology

At some point in your software career, someone on your team is going to suggest introducing something new to your tech stack. Whether it's a large or small request, discussions around these suggestions can often become contentious.

In the field of software engineering there are no hard rules, and there are a lot of different ways to achieve the same end result. Our discipline is not so different from lifting weights or dieting in that respect, and we're also vulnerable to the kind of tribalism which permeates those segments of the health industry. Technology workers are susceptible to forming very strong opinions on tech stacks.

It's an important skill to navigate these discussions in a way where the proposed technology gets fairly evaluated without shutting down the person making the suggestion. Sometimes saying "no" is the obviously correct course of action, but if you do that every time then team morale will take a hit. Being Socratic and getting the other party to explain things from the ground up is a much more productive method for handling these conversations.

The following are some questions I've found to work well in this situation.

What problem are we actually trying to solve?

This doesn’t need much explanation—we need to understand the problem being solved in order to come up with a solution.

At this stage we're also trying to identify early whether the "problem" being solved is simply our team member wanting to use this technology. Technology for technology's sake is never a good idea–software engineering is about solving problems to deliver customer value. In my experience, a lot of tech stack suggestions ultimately boil down to engineers wanting to use something shiny.

How might we solve the problem with our current technology?

In almost all cases, there’ll be some way of solving the problem using your current stack. If we can’t find a solution then either it’s a super hard problem or we haven’t thought hard enough about it.

Using the current technology might produce an unwieldy solution—that’s okay. In order to accurately compare new vs old we need to have something to compare with in the first place.

Going through this process will often tease out hidden requirements and complexities. It might turn out that the new technology solves the problem elegantly at a superficial level, but there’s some added detail it doesn’t handle well. Coming up with a solution using the old technology forces you to think about the problem from first principles and can reveal additional questions to ask of the new technology.

Do we understand the costs of adopting this new technology?

I mean fully loaded costs here. Among other things, we need to consider:

• Licensing fees
• Time to upskill team members
• Monitoring requirements
• How “nice” is the API? How much cognitive load will this require from our team to use?

In a similar vein to previous questions, a comparison between technologies is hard to make without understanding costs.

Will this new technology eat the old?

In some cases it’s completely fine to have different solutions employed across the business. Validation libraries, for instance, tend to have lightweight API surfaces and it’s probably not too big a deal to have two different libraries in play.

Multiple options for larger pieces of the stack is often problematic. It’s easy to underestimate the cost of context switching. Software engineering is hard and requires a lot of mental focus—having competing solutions in the same codebase takes up valuable mental cycles which could be used solving problems and creating customer value.

How can we start small?

Changing the tech stack always carries risk. Risk isn’t inherently bad, but it usually pays to minimize it. Is it possible to drive a small scale proof of concept to demonstrate feasibility? Have you done it?

Have you hashed this out with other senior engineers on the team?

…and where did you document the outcomes?