The Challenge of Introducing New Technology

Feb 20, 2020 - 9 min read

Over my career I have worked with multiple software development teams where questions like these have come up:

"Should we adopt React even though we have a few Angular 1.x applications?"

"Do we want to build this new project in a different language from what we are used to?"

"Should we adopt GraphQL?"

Introducing a new technology - whether it's a new language, framework, or cloud computing service is something that happens very often in software development teams. It's usually done when teams are trying to build a new project, or are just looking to accelerate their development efforts on existing projects. Deciding to go forward with a new technology can be a huge undertaking. This post is meant to talk about some of the things that developers should think about before they pull the trigger.

Why it's important to strive for consistency

Assuming the new technology will solve an already "solved" problem across the stack, you risk breaking some level of consistency. Consistency in development teams is very important. It exists to help developers build onto systems in a known, predictable way. Consistency exists to speed up the development cycle and make testing a breeze. It makes code reliable and predictable, which opens the door for automation. It makes on-boarding new developers easier, too. There's no doubt that teams should be be striving towards some level of consistency throughout their codebases.

The cost of introducing something "new"

The second you add a new technology to your stack, you face a number of challenges:

The learning curve challenge

If it's a new technology that the team is not familiar with, there is going to be a learning curve. This means that for an indefinite number of days, development velocity will be lower until the developers get more familiar with working with it.

Initially, nobody is an expert

If there are no experts in the technology on the team, that means that the initial code that developers put out will likely not be the best quality, or follow the best practices that developers learn over time. This may make code reviews challenging, which will result in a lot of "Looks Good To Me" pull request approvals.

The cost of maintaining both new and old

If a new technology gets introduced, you have to maintain the old technology alongside the new until the old version has been replaced. This slows down on-boarding and adds the burden of how much a developer needs to know to do their job.

Depending on how successful the team was at removing the old piece of technology, if yet another new thing gets introduced on top of the new technology you suddenly have made the maintenance that much worse. I've worked on projects that had a bit of jQuery, Ember, and Angular. When you're working in a project like that it's easy to become a "jack of all trades, but a master of none".

It's difficult and slow to rewrite old code

Based on my example with the multiple front end frameworks in the same project, you can imagine how difficult it is to write all new things in the latest and greatest framework included in the project. Especially if you are just going in to fix a bug, a lot of times you just end up fixing the bug using the library surrounding the code. A lot of times you may not want to go through the effort of re-writing / replacing old code, especially if the cost to replace is high relative to the wins that might come with rewriting it in a new technology.

It is worth it?

This answer depends on a number of factors that I will get into later. When you introduce a new technology, you do so with the promise that the long-term payoff will be worth the high up-front cost and the continued cost of maintaining and re-writing the old parts of your code that are not using this technology.

Why it's important to drive technology forward

As years go on, technology improves and so does the tooling developers use to create products. As the technology improves, so does developer experience, automation, build times, performance, code safety, and tooling around testing. For the most part, the time it takes developers to solve problems and ship code decreases over time as the tools get better.

Just factoring in build and deployment times alone, the ability to get code in production more quickly is such a big thing. The time it takes to deliver value to customers makes a huge difference to any organization.

At a previous job we went from "deployment Tuesdays", where the deployment would take the better half of a morning, to deploying multiple times per day. Not only did this help deliver value to customers quicker, it also was a huge morale booster for the developers on the team.

Knowing when it's time to introduce "a new thing"

I think most developers tend to want to always try out the latest hot, shiny piece of technology, especially if there is a lot of hype around it in the community. While it's tempting to just jump to introduce something new, I believe there should be a good reason to do so, and not to just do it for the sake of it.

Here are some signs that make you want to consider an upgrade:

Build times are slow
Performance isn't up to par
Developer experience is awful
The developer community is becoming smaller and less active over the years
Documentation for the tooling isn't good
Code quality is not where it should be

It's important to note that even if you are experiencing some of the issues described above, it might not be good enough reason to change the tooling you're using. It's entirely possible that you can solve these problems with the existing tooling the team is using.

Questions to think about when evaluating a new technology

Once you start the process of deciding whether or not it's a good idea to introduce a new technology, here are a few questions for you to think about. These questions have helped me in the past to evaluate libraries and frameworks, which ultimately helped me pitch to the team that it would be a safe bet to introduce the "new thing".

Will the new technology help address some of the problems mentioned above?
Does the technology have a large community?
Does the technology have the backing of big organizations?
Does it have a great developer experience?
Does it have great documentation / tooling surrounding it?
Does it score high on the developer survey?
Do any people on the team or organization have experience with it?
Will the technology ultimately help the team accomplish business goals?
What are other options out there that accomplish the same goal?
Could you build your own version of the technology instead?
How easy would it be to hire a new developer if we move forward with this technology?

Getting buy-in from the rest of the team / organization

Ultimately, even if you think this new technology will be perfect for the team, unless you have a lot of pull in the organization, you will need to get their buy-in and support. This is imperative if they are going to be the ones working with it on a daily basis. Here are some ways to go about doing this:

Develop of proof of concept / demo for your team

When I was working at Campus Labs in mid -2016, I had a huge interest in React. At the time we were using a mix of JQuery and Angular 1.x throughout the application we were working on. I pitched it to my manager at the time, and he suggested I come up with a demo on how it works. I ended up re-writing the "search everything" part of our application in React in a weekend, and gave the team a demo of how it worked. The team was impressed, and so was my manager. Ultimately we agreed as a team we were going to go forward using React instead of Angular 2, which was in beta at the time.

Looking back, the demo was important for my team and manager to see. For one, they could see the before and after code to compare the two separate bits of code. Aside from the initial JSX shock, they could see that there was some promise to the hype behind it. React - though it was relatively early on - scored well on most of the questions mentioned above. Important, too, they could see my enthusiasm as I raved about the developer experience. It also probably helped that I re-wrote part of the app that the developers were familiar with. It showed team members how React could fit into the application as a whole.

Pitch using the new technology in a small part of the system as a whole

If you start to introduce your new thing in a small isolated part of the system, it will mitigate risk. That way, if the experiment fails, it won't be super hard to recover from the sunk cost.

At Mersive, we were evaluating React Native as the potential option for an upcoming mobile app, and potentially more mobile apps in the future. Considering the mobile app we were trying to build was pretty small, it seemed like a good opportunity to try out React Native. If for whatever reason it doesn't pan out, it won't be a huge deal to re-write the app using QT or even native Android / IOS.

Present a lunch and learn for the team

A lot of times you may be one of the only people at your company that is knowledgeable in a certain technology. Perhaps you saw success with it at your last company. Sometimes you just need to spread the "good word" and let people know about it.

Recently, in a meeting a developer was suggesting we move to Kotlin instead of Java going forward. A few weeks later, he ended up giving a lunch and learn explaining a lot of the languages benefits and syntax nuances. By the end of the presentation I was ready to jump ship on Java and move forward on Kotlin. Enticing people with free lunch and spreading knowledge isn't guaranteed to work, but it definitely doesn't hurt.

What if you can't get buy-in?

Through all of your efforts, you may get feedback that ultimately shatters your plan of introducing this new technology. Maybe the organization isn't ready to take on a new programming language or framework considering there are other immediate concerns. This can happen, and when it does you have to respect the reasons why you shouldn't introduce it at this time.

Even though you got shot down doesn't mean you need to give up. Company culture permitting, you can still hold lunch and learns or create Slack channels to help spread the "good word". If you are passionate about a technology, I encourage you to attend meetups and work on your own side projects.

Coming up with a plan of attack after you introduce the new technology

Let's say you were successful in convincing the team to use this new technology, what should you do next?

Come up with a plan detailing where to start the introduction
Decide how far to go to convert any "old" technology into the new one
Hold a lunch and learn for other developers in your organization
Create a meetup group or a Slack channel surrounding this new technology where people can ask any questions they may have about it
Have meetings on some cadence with people that are interested in this new technology
Pair program with one or more other members of the team
Advocate that the company assist with funding for courses or books on said technology so the knowledge can spread across teams

Closing thoughts

Deciding when it's a good time to introduce a new technology is not easy. It's important to keep in mind the problems and challenges that come when you decide to pull the trigger. Initially it might be a struggle, but over time as the development team becomes more knowledgeable in the technology, the severity of these problems will decrease. Doing so can really change the momentum of the development team and provide huge wins for not only the developers, but the organization as a whole.