Setting up a Kotlin community

How the Kotlin journey began

In February 2021 I started working at Rabobank , half a year prior to writing this blog post. After one month, I overheard some of my colleagues talk about Kotlin. This moment was the perfect opportunity for me to pitch the use of Kotlin within the team. They agreed to start using Kotlin as on one of our microservices and (within two weeks!) we converted about 12,000 lines of code from a Java-based microservice to Kotlin alongside planned sprint work.

My manager agreed that the adoption of Kotlin was quite straightforward, without too much risk and that the benefits of the language outweighed the downsides. We discussed the possibility of spreading the use of Kotlin within the organization, because it could benefit many other teams as well.

As such, together with two fellow developers and Rabobank’s community manager, we set out to create the “Kotlin Movement”, to achieve our goal of spreading the use of the language within the organization. As part of the initiative, we started the bank’s internal Kotlin Community where Kotlin developers could meet and ask questions, gave different talks about the subject and created a guide for developers about the risks, opportunities, challenges and experiences of adopting Kotlin at Rabobank.

The big merge with the Java Community

As the community grew, the community manager at some point asked us why we didn’t aim to merge the Kotlin community into the Java Community, because they were so closely related. Since we all agreed that would indeed be a great idea, I pitched it to the Java Vakgroep (the internal Java “advisory board”) on the 12th of May, and the proposal was accepted. Therefore, from the end of September, the Kotlin Community and the much larger Java Community at the Rabobank will officially become the “Java and Kotlin Community”. Since it will signal to hundreds or perhaps even thousands of developers within the organization that Kotlin is a serious and viable alternative to Java, this was definitely the pinnacle of our journey.

How did we convince the Java community?

Before we convinced the much larger Java community to include Kotlin as an integral part, we had to pitch our idea. We asked ourselves: what can we learn from it? Because if we can learn from it, we may apply some new insights to similar endeavors, thereby increasing their chances of success.

Good to know: the importance of pitching your idea can't be underestimated. This may be broken down into how you pitch, as well as what you pitch.

What probably made it easier for me to pitch Kotlin to my peers was the fact that I feel very passionate about it. This showed in my enthusiasm, which was often caught on by others. And by telling the story to more than a hundred people before eventually pitching it to the Java Vakgroep, I also started to learn what arguments people found compelling and what triggered them. This grew my confidence when telling my story and increased my persuasiveness.

But, of course, what you pitch is at least equally as important. We wouldn't have been able to set up a community and make an impact if Kotlin wasn’t so compelling for large enterprises.

Present the benefits

For instance, with Kotlin, the main selling points are features like non-nullable types that make your code safer and less error-prone, whereas features like data classes make your code less verbose. Every developer who has ever written getters and setters will find Kotlin’s data classes a relief, and every developer who has ever seen a NullPointerException will immediately understand the benefits of non-nullable types.

Meanwhile, the fact that Kotlin can be learned within days instead of months, because you can still use the exact same libraries and similar constructs as you would in Java, makes onboarding new employees painless. The organization can still recruit for Java developers, while even being able to attract additional Kotlin enthusiasts.

Besides, it is very easy to migrate to Kotlin. Since Kotlin has full interop support with Java, you can gradually migrate without big bang releases. Combine that with the built-in converter in IntelliJ, and you can literally convert thousands of lines of code to Kotlin in a matter of weeks, like we did within our team. All in all, the arguments for using Kotlin within a large enterprise organization turned out to be quite compelling when pitching the idea. The risks are low, the gains are high. It’s backed by large organizations, and is likely not going anywhere for a long time.

Share your vision and find ambassadors

The second thing I learned is about how to propagate an idea throughout the organization from the bottom-up. It turned out to be quite simple, actually, and basically comes down to the following: define your vision and create a plan. Find the right people, and execute. Maintain your vision, but adjust your plan according to newly acquired knowledge and changing circumstances. In our case, I was also able to find really great people to set up the initiative. Without them, the journey would have been much more difficult if not impossible, would have taken much more time, and it wouldn't have been nearly as rewarding.

Make sure you are on the same page

Every step along the way we discussed if we were still on the right track, yet we all shared the same vision about Kotlin’s place within the organization. Whenever we pitched the idea to other people, we were often introduced to other people and obtained new insights, and so forth. And because of these new insights, we eventually pivoted from an approach of just pitching the idea of using Kotlin to different teams, to an approach of changing the Java community to include Kotlin - thereby changing the mindset of developers from a higher level.

Take ownership and go for it!

Finally, I learned that the only way to make a difference is to go out there and do it. Because no one is going to do it for you. People around you may be enthusiastic about your idea or even help you along your journey, but until your idea is really “established”, you are responsible for taking ownership. To put it more bluntly: if you only complain about what you don’t like about something and don’t put in the effort to change it, you will just keep complaining about it and nothing will change. Execution is key.

And so, that brings us to the end of the article. With my story and the accompanying analysis I hope that I inspired you to make a change within your organization. Please, keep in mind: no matter what you want to change, you have to start executing, because no one will do it for you. For example: running is a great idea to get fit, but nothing will happen until you put on your running shoes and start running.