“Kotlin is great and I really want to use it. But how can I convince my management?” This is the most frequent question I get asked after a talk. In this post, I explain how we introduced Kotlin and show arguments, strategies and tricks that can increase your chances of success. I keep the fingers crossed for you!

TL;DR

• Explain the advantages of Kotlin
  • Increased productivity
  • Fewer errors
  • Motivated developers
  • Increased attractiveness for applicants
• Clarify that introducing Kotlin comes with low risks.
  • Reuse of the existing knowledge about the Java ecosystem
  • Kotlin is not a complicated language.
  • Kotlin is easy to learn - especially for Java developers. No paradigm shift.
  • Stepwise migration possible. Parallel usage of Kotlin and Java possible.
• Know the valid reservations about Kotlin. Be prepared when they come up. But stay honest and balanced.
  • Further development depends on JetBrains
  • Poor support in Eclipse and NetBeans
• Get a foot in the door.
  • Start introducing Kotlin in a project with a small code base and less business impact.
  • Test suite projects or internal tools are good starting points.
  • It’s much more likely that the management will agree to this compromise.
  • Use the gathered experience to argue for an extended Kotlin usage.

The Story of Kotlin at Spreadshirt

At Spreadshirt, we started to introduce Kotlin nearly 2 years ago, in August 2016. We started to use Kotlin in a test project. This was a great starting point as we didn’t touch any productive code but were still able to gather experiences. We were so enthusiastic by Kotlin that we extend its usage. Afterward, we started our first service purely written in Kotlin. Little by little, other teams started to adopt Kotlin and also used it for new services. As of today, Kotlin has the following adoption:

However, most of the Kotlin services are of a small or medium size or are internal tools. Java is still our breadwinner.

For me, there are two factors that eased the introduction of Kotlin at Spreadshirt:

• Microservice Architecture: As our platform consists of independently deployable units, it’s much easier to use new technologies and language when you start a new project.
• Self-Organized Teams: Our teams have many freedoms when it comes to choosing technologies. They decide on their own but also have to carry the consequences if a certain technology turns out to be bad in maintenance or operation. There are only a few guidelines. For instance, we usually stick to the JVM ecosystem.

All in all, I claim that today Kotlin is the first choice for new services in many teams at Spreadshirt.

That was our story in a nutshell. Based on our experience, I like to give you some recommendations, strategies, and tricks that may increase your chances of success when it comes to convincing the management or architect of Kotlin.

Explain the Advantages of Kotlin

• Increased productivity
  • For instance, data classes and the expression support highly reduce the boilerplate and lead to concise code.
  • Kotlin has built-in support for many Java best practices and design patterns.
• Fewer errors
  • For instance, due to immutability and nullability.
  • That’s hard to measure objectively, but I can confirm this based on my own experiences.
• Motivation for developers. Happy developers are productive and do not quit.
• Increased attractiveness for applicants. Modern languages attract skilled developers. We at Spreadshirt already had applicants asking explicitly for Kotlin.

Clarify that Introducing Kotlin Comes with Low Risks

• Reuse of the powerful and well-known Java ecosystem. We stick in our beloved JVM ecosystem and can reuse our knowledge about Java libraries, frameworks, build tools, artifact repositories, CI, CD, IDEs, monitoring, logging, the JRE, test tools, deployment, provisioning and the JIT compiler. This is a huge advantage and should not be underestimated. This significantly shortens the learning curve and make you productive. Introducing Kotlin is not disrupting the company’s technology stack.
• Easy to learn.
  • Especially for Java developers.
  • No paradigm shift. Like Java, Kotlin is an object-oriented language. It just has more functional features.
  • Learning the basics of Kotlin can be done within one or two days with the Kotlin reference. It’s not a complicated language - and that’s great.
• Interoperability with Java.
• Stepwise migration possible. You can use Kotlin and Java at the same time within a project.
• Brilliant IDE support with IntelliJ IDEA.

Know the Reservations about Kotlin

First of all, don’t consider your management or doubting colleagues as your evil enemies. They usually just want to protect the project from additional complexity or don’t want commit to a “hyped language with an unknown future”. Take their valid reservations seriously and express your understanding. Try to understand their intentions and viewpoints. Otherwise, they will remain in a blocking stance. Be honest about the risks and consequences and offer compromises. So yes, this is also about psychology.

That being said, let’s go through some typical reservations starting with the two most important ones.

Uncertain Future of Kotlin

“Kotlin is only the next hyped JVM language”

“The further development of Kotlin depends on JetBrains”

Good point. JetBrains is not a small company (700 employees) and they are healthy but they are definitely not Oracle, Microsoft or Google. This is a valid and serious argument. At least, you could raise the following objections:

• Kotlin is licensed under the open-source license Apache 2. It’s not proprietary and can be developed without JetBrains - at least in the theory.
• Google commits to Kotlin by making it an official language for Android development (announced at Google I/O 2017). For instance, they are developing dedicated Kotlin APIs (like Android KTX).
• The Java ecosystem embraces Kotlin.
  • Spring 5 introduced Kotlin support (dedicated Kotlin DSLs and extension APIs, nullability support)
  • Gradle offers a Kotlin DSL for writing Gradle build scripts as an alternative to Groovy.
  • JUnit5 also supports Kotlin. They even name Kotlin in the official user guide as a motivation for changing the default test instance lifecycle.
• The Google Search Trends are clearly showing a stable increase of interest in Kotlin.

● Kotlin ● Scala ● Groovy ● Clojure

All in all, Kotlin is definitely here to stay.

IntelliJ IDEA as the Fixed IDE

“I want to stick to Eclipse.”

“We have to use IntelliJ IDEA.”

Yes, that’s true. You have to use IntelliJ IDEA. The Kotlin support in other IDEs is poor, period. It’s not much fun to use Kotlin in Eclipse or NetBeans. Yes, there is an official Eclipse plugin which is developed by JetBrains. But for me, it’s barely usable. Let’s be honest: You can imagine how much interest JetBrains has to offer a fully-fledged Kotlin tooling in Eclipse next to their own commercial product. Selling licenses is the primary motivation behind developing Kotlin.

The discussion about the “best” IDE is emotional and nearly religious in the Java community. There are zealots and fanboys in every camp (this includes me). So if your team consists of confirmed Eclipse users, convincing them will be really tough. Honestly, I believe it can be nearly impossible. Unfortunately, this can become a serious show stopper for introducing Kotlin. Even at Spreadshirt, one team rejected Kotlin due to this reason.

At least, keep in mind that the community edition of IntelliJ IDEA already contains the Kotlin tooling. So there is no need to purchase a license. By the way: I used the community edition for a long time and it worked out pretty well! I missed nearly nothing.

Training Required

“Every developer has to learn a new programming language.”

Yes, depending on your team structure, that can be true. But this argument can be easily moderated by pointing at Kotlin’s advantages. Let’s recap them:

• Kotlin is easy to learn. It takes one or two days to learn the basics. Afterward, it’s learning by doing.
• Reuse of the existing knowledge about the Java ecosystem.
• Kotlin is similar to Java.
• Kotlin is not a complicated language.
• No paradigm shift.
• Learning a new language can be great fun and a huge motivation for the developers.

Get a Foot in the Door: Start Small and Gather Your Own Experience

The web is full of endless list of advantages offered by Kotlin - just like mine above. It nearly sounds like promises of salvation. Most likely, these claims of third people won’t convince your management or architect. The key to success is to gather your own experience with Kotlin. With these experience you are more credible and can argue way better:

“Hey management, we tried Kotlin and experienced concrete advantages. We could reduce the boilerplate significantly with data classes and expressions. Besides, we also feel that it’s more unlikely to introduce bugs due to immutability and null-safety. And finally, it was great fun! Can’t wait to go to work tomorrow!”

Concrete experiences are persuasive. But how can you gather those experience if we are not allowed to use Kotlin in the first place? Simply re-writing an existing service without having a concrete business benefit will be impossible to sell. I recommend offering a compromise. Some options:

• Start using Kotlin in a test project. So you are not touching any productive code. The Kotlin code won’t have a direct impact on the business. So the impact is comparatively small and the code base and complexity is of manageable size. At Spreadshirt, we followed this approach and it worked out pretty well.
• Internal tools are also a good candidate.
• Use Kotlin in parallel with Java in the same project. You only use Kotlin for new features and leave the existing Java code untouched. As Kotlin works nicely together with Java, this is possible. But mind, that you will now force all developers of this project to learn Kotlin and to use IntelliJ IDEA. Moreover, there are also valid reservations about using multiple languages within the same project in general as it increases the complexity of the project. That’s why I claim that this approach might be hard to sell.

Call it an “experiment”. This might also improve the acceptance. So the management still feels that this decision is reversible every time. In fact, that’s the truth. But at least, you get a foot in the door. It’s much easier to extend the Kotlin usage after you started to use it.

Your Story Matters

I’m really interested in your story of introducing Kotlin in your company. Or if you tried and you couldn’t convince the management or your fellow developers. In both cases, please drop a comment.