Like any modern technology company, we use many tools to bring our banking platform to life. Many of our backend services, for example, are implemented in Java. And our engineering team has tried out both Scala and Typescript — but later decided it wasn’t for us.
As part of our way forward, I’m excited to announce that we are moving towards adopting Kotlin as our major development language for our backend services.
In this article I’ll outline why and how we came to that decision.
Why Kotlin?
I like to describe our engineering culture as pragmatic. We don’t pick tools because they are “shiny,” “new” or “theoretically better.” Instead, we pick tools because they help us solve customer problems in a more simple, clearer way. Simplicity is one of our company values after all. It’s also another reason that our “Get Stuff Done” mindset carries over to the name of our “Get Stuff Done Days (GSDD).”
We went down the path of exploring Kotlin for a number of reasons including the following:
- Kotlin is easy to learn — Kotlin has an incremental learning curve. It doesn’t look too different from Java and our team found it easy to feel productive when they started learning and playing around with it.
- Kotlin is opinionated — unlike Scala or Javascript, Kotlin avoids the social problem of agreeing on style with engineers by providing a single, opinionated way about how to do something. Since engineers spend more time reading code than writing code, it’s helpful to read code to understand what the business domain is than deciphering cryptic code simply because the language allows it.
- Kotlin has nice language features that get out of the way — nullable types, (optional) immutability at a language level, more complete functional concepts built into collections, proper lambdas, and named arguments enable more, with less code.
- We can adopt Kotlin incrementally — Jetbrains really thought about Java Interop carefully and considered how you can easily migrate towards Kotlin bit by bit. You can start with Kotlin simply by dropping your compiler into your maven build process. Teams can benefit from Kotlin (e.g. start by writing tests in Kotlin) without having to convert entire codebases, build systems, editing environments, etc. Boom! Immediate ROI. (NOTE: We do have a convention of not mixing Kotlin/Java codebases for different reasons)
- Kotlin has a big (and ever growing) community — I think that big communities make a big difference. Even though I have strong negative feelings towards Maven, I cannot argue with the huge support of plugins and other capabilities that are available because of the community. With Google announcing support for Kotlin on Android, it widens the support that comes along with the ecosystem. For us, it also means that there is more potential knowledge sharing across our Android and Backend service teams.
There are many other reasons we ended up with Kotlin, but I am very happy with the result. It means our engineers have a more productive toolkit that lets them focus on building software that addresses real customer needs. All this without leaving a build, deployment, and tooling ecosystem that already provides a lot of value.
How we chose Kotlin
Since we’re becoming a larger company, standardizing the implementation language helps engineers move from service to service and focus on learning the domain, rather than a completely new tech stack. It also means that teams benefit from the same platform infrastructure (logging, monitoring, etc) that enables us to spin up new services quickly and enables much more productivity.
Our process for picking Kotlin looked like:
- Enough engineers talked about Kotlin as something that we should look into.
- We formed an interest group of engineers to discuss the pros/cons and process of if and how we should proceed. After this initial meeting, we agreed on a set of common criteria before choosing to adopt a new language like Kotlin.
- We agreed that during the next GSDD people would investigate a number of concerns. Others completed some koans and katas to learn more about Kotlin and its strengths & weaknesses.
- After the GSDD, we gathered again to discuss the learnings, concerns and risks. Not all of these were addressed, so we decided how we might learn more and mitigate this for the next GSDD. A development team ported a small service to Kotlin by using the auto conversion tools and with some cleanup, put it into production to learn more about experiencing it at a slightly larger scale.
- We met again to discuss concerns and we found that most of these were addressed. Then we started thinking about how to adopt and roll-out Kotlin.
- We tasked one of our engineers to communicate and a roll-out plan for Kotlin.
- The interest group got together to agree on the communication, support, and roll-out plan and I communicated the result to the organisation.
On our journey of adoption
We’ve already managed to convert 10% of our GitHub repositories are into Kotlin and we are learning more about the ecosystem and gotchas that it, like all languages, has. I’m betting that the developer-usability focus that Jetbrains brings will help Kotlin succeed in becoming a popular language that engineers enjoy developing in. I know that our engineering team enjoys it too.
Interested in writing some Kotlin with us?
If you’re interested in Kotlin and would like to join us on the journey of building the mobile bank the world loves to use have a look at some of the roles we’re looking for here.
