On Adopting New Tech

Most of us love new tech. We’re always after that new shining piece of software that’s going to make us more productive or will stretch our minds to think differently.

As for myself, GitHub’s trending page is my homepage, and I’ve tried a variety of programming languages (such as Rust, Go, Lua, Elixir…), frameworks (Django, Flask, Express, Rails, Phoenix) and even platforms (I started as an iOS / React developer and then moved to server land as a backend developer at Cheesecake Labs).

Unfortunately though, it’s not always that we can apply new tech to an existing project, due to a variety of reasons. Maybe the team is already very used to another stack and they don’t feel like starting from scratch, maybe the upper management can’t see the value of a change of gears. So how should one proceed?

We’re going to discuss how can we adopt new technologies, languages and frameworks by interviewing two developers here at CKL that spearheaded some changes.

Java / Kotlin

(Natan Grando, Software Architect)

It wasn’t obvious back in 2016 that one should use Kotlin (remember that Google just announced Kotlin for Android in I/O ‘17). Java was a much safer, official and available option in that point and switching to Kotlin could sound too adventurous, in contrast with the whole Objective-C versus Swift situation where Apple clearly favors and pushes Swift as its main application development language.

In this short interview, Natan explains how he conducted this change in a sustainable way, making Kotlin the de facto Android development language at Cheesecake Labs.

– Why did you want to check Kotlin out?

I’m very involved with the Android community and I’ve been reading a lot of blog posts about the language. I decided to create a personal project to test Kotlin capabilities and soon afterwards I found that the language was pretty good.

Since we’re always starting new projects here at Cheesecake Labs, I talked to the Android development team and asked them whether they were open to start a new project with Kotlin or not. They were all on board with the challenge and the project became a success case for us.

– CKL now uses this stack, how did you manage to convince people to adopt it?

We do have a lot of autonomy here at CKL and people are very open to new things. I think that after demonstrating that the technology was mature through my personal project, everyone was convinced that it would be nice to try it out in the company’s projects. Another example is the architecture we use on Android, we started with MVC, then moved to VIPER and now we’re experimenting with MVVM.

– Do you have any tips on how to facilitate the adoption of new tech?

Be very thorough with your research. Adopting new tech because of hype is bad, you should always check what the community is saying about it and talk to your teammates.

Gradual implementation (if possible / applicable) is nice. With Android for example, you can start writing new modules using Kotlin and afterwards trying refactoring some of old Java code, making sure everything is working as expected.

Angular / React

(Daniel Leite, Senior Frontend Developer)

Even though Angular has a strong company behind it (Google) and enjoys very good community support, for some applications its intricacies seemed a little too much. Then along came React, the new kid on the block, providing a gentle learning curve that Daniel thought was worth experimenting with.

– Why did you want to check React out?

I was working with Angular and sometimes I did things without fully understanding what I was doing. Angular has many layers and complexities whereas React is much lighter . I felt I had full control when working with React and when Redux came along, it changed my way of thinking about immutability. This led to fewer bugs in our code, as one can imagine.

– CKL now uses this stack, how did you manage to convince people to adopt it?

CKL is growing fast, and it’s been difficult to keep track of everyone’s code. To deal with this issue,  a “boilerplate” repository was created to help people set up their projects. Other thing that helped a lot was giving some workshops and BBL ’s (brown bag lunch talks) about this new tech. And of course, code reviews are a vital part of the process.

– Do you have any tips on how to facilitate the adoption of new tech?

If you have something that works, you don’t have to rewrite code just for the sake of it. On the other hand, if your stack is setting you back, maybe it’s time to start thinking about moving to a new stack. That way it’s easier to explain and convince the managers why the change is necessary.

Technology is all about the community . Look for open source libraries and solutions, try to see beyond the hype, understanding how people use this particular piece of tech in production and hear their war stories.

Somewhere in the middle

(Rodrigo Landerdahl, Senior Full Stack Developer)

Rodrigo is very fond of functional programming (check out his post about Clojure and GraphQL here ), specially Erlang, and one day we were talking about the fact that people were very curious about Elixir (a new programming language that’s built on top of the Erlang Virtual Machine, read more here ) but would not even listen should we talk about Erlang itself.

We quickly realized that Elixir was the middle ground between the Prolog-ish syntax of Erlang and the familiarity of a language such as Ruby. That started a conversation about “somewhere in the middle”, a term that I think is very interesting. We call Elixir “somewhere in the middle” because Elixir uses Erlang’s semantics and mechanics, but does so using a syntax that’s closer to the people that are used to Ruby, Python and the like. It also offers some modern facilities such as a good package manager.

In the context of introducing new technologies, Elixir is in a interesting spot. Engineers that want to work with Erlang, but can’t do so because of the unfamiliarity the language boasts, can introduce Elixir as a much more comfortable alternative. The same could be said about ReasonML being sort of a gateway to some understanding of OCaml.

Some inspiration

At Google I/O ‘17, we’ve had a presentation called Life is Great and Everything Will Be Ok, Kotlin is Here (Google I/O ’17) where Christina Lee (Software Engineer at Pinterest) talked about adopting Kotlin. Her tips and strategies have a broad appeal, being applicable to almost every new tech out there.

She breaks down the adoption challenge in 3 parts: You, management and your team. Of course, “you” is the easiest part, where you must show enthusiasm and talk to people about the new tech. But the easy part is being enthusiastic, because people will have questions and most likely they won’t like feeling unproductive.

The second part is talking to management, and that’s tricky, because being an engineer, you’re mostly comfortable talking about the technical aspects that make this new tech useful to your company. But on most cases, management doesn’t speak tech engineering lingo, so we must strive to find a middle ground where we can have a conversation. A good tip is trying to explain how, for instance, a safer type system implies less bugs, and less bugs means satisfied customers. Speak management.

Last, but certainly not least, there’s the team. Well, if you’re bold enough to introduce new tools, you should be able maintain these tools and document everything you’re doing to help future onboarding processes. You need to be the go to person to aid your team in their transition.

Wrapping up

Adopting new technologies is certainly no easy task, involving not only an effort to learn and step out of one’s comfort zone, but also convincing people from both sides of the aisle (tech and business). And of course, perhaps not always a necessity. Do a lot of research, try finding war stories and case studies for the targeted tech before trying to convince everyone to use it. If even then, you decide that the new tech is the way to go, be there for the other engineers, document every process and be proactive in helping them getting their productivity back, making the process as smooth as possible. Happy coding !