There’s no shortage of posts extolling the virtues of Kotlin and the reasons companies decided to pivot their stack from using Java to Kotlin. At FREE NOW, we were faced with making the same choice as well. While we’re already diving deep into what makes Kotlin great, we’re also letting the language grow organically by giving each team the power- and responsibility- to decide which programming language, be it Java or Kotlin, they’d like to use for their next project. In my short but sweet eight months that I’ve been working here, I had the opportunity to introduce Kotlin to the team I’m working in, Allocation, and tried my best to discuss why it’s a good choice for us going forward.
By now there’s a decent chance that you’re not only familiar with the language, but you’ve also decided whether or not it’s a good fit for you or your team. Instead of rehashing arguments on why Kotlin makes sense, I’d like to talk about the human factor: what is it like to introduce Kotlin to a team that has mixed emotions about the language? Some developers were ambivalent; the language is just the engine to drive the business logic and meet deadlines. Others were skeptic or even against the use of Kotlin and didn’t see a benefit in including a new and unproven language to the stack.
The best example is a practical one, and what follows are my experiences working with Kotlin in the Allocation team and some suggestions I’d give to everyone thinking about introducing Kotlin in their team.
Make a Sales Pitch
Introducing a new technology is best done by someone already experienced with it. If possible, decide on a small but not insignificant component- in our case a new asynchronous messaging service- that will be written in Kotlin. We sat down together at the end of this service’s development to figure out how we felt about our first brush with Kotlin. The big questions on our mind were: did the implementation go well? Did we already uncover any problems with the language? What benefits did it actually give us versus a Java implementation? How much longer would the implementation take if someone inexperienced with Kotlin wrote this service? How long will it take to get every developer up to speed?
To be honest, there was- and still is- some apprehension. Kotlin, written in a Kotlin style, doesn’t read as easily in practice as someone accustomed to Java. Many idioms or syntactic features were unknown and made understanding the code difficult. Showcasing the code had to be done line-by-line, examining what was happening under the hood and understanding the benefits of such an approach. Topics such as null-safety, immutable-by-default variables, extension functions and the like were met with optimism, but Java interop and especially Spring interop worried our team.
For some, the features weren’t convincing enough for them to say that they’d like to continue with Kotlin. They asked for a killer feature, one which proved that Kotlin was beyond a doubt superior to Java and a clear reason to replace it. There was no satisfying answer to this question, but it was nevertheless agreed that more understanding was required before making a complete assessment. In the end, we decided that Kotlin was worth exploring further and we’d start writing new services in it.
Introducing Change Slowly
Once Kotlin had been introduced in the team, it was important not to rush the integration. We deliberately focused only on one or two Kotlin services at a time while the rest of the team continued to develop in Java. We made sure that every developer had the chance to implement one of the new services so they’d be encouraged- and forced!- to try and learn the language. We gave all of the new services more time during grooming so there wasn’t any pressure to release these services at the same speed as our Java services. In retrospect, this was a good decision.
Be aware that not everyone will dive straight into Kotlin. A lot of talk on the internet has been about how easy it is to move from Java to Kotlin, but that’s not necessarily true. Good Kotlin code isn’t necessarily good Java code and vice versa. Developers accustomed to streams might not know about Kotlin sequences, for example. In those cases there are two methods to reinforce learnings and help every developer get to the same level of expertise: pair programming and pull requests.
Sharing knowledge With Pair Programming
To be honest in critiquing ourselves, this is an area we should have utilized much more. Most grievances came because developers worked on their code alone and asked for help when they were frustrated and up against a wall. In such circumstances we’d sit down together to debug the problem and come up with a solution. A lot of learning happened in that time which would be shared with other developers, but the initial frustration remained. This only improved over time and as we started asking for pair programming more often which greatly helped to lessen the burden of learning Kotlin.
Reinforcing Learnings With Pull Requests
A Pull (or Merge) Request is ideal for diving deeper. Initially, there was a lot of Kotlin code written mutably, with “var”s sprinkled throughout the codebase and little thought given to advanced features like case classes, when expressions, extension functions and so on. While the comments should be optional (although I do advocate for removing mutable and nullable code whenever possible) it’s helpful to give descriptive comments that both identify the problem and also how to rewrite the code as an example. This gives an additional benefit not only to the implementing developer, but all others that are viewing the pull request to use the optional refactorings in their own code.
Accepting That Not Everyone is on Board
It’s been around six months since we started working with Kotlin. From starting with a single asynchronous messaging service, to developing single services to developing every new service in Kotlin, it was a slow but deliberate process. At first, there was a lot of criticism and we honestly didn’t do enough to prepare developers to write Kotlin code. Some services were written in Java, not because they had to, but because the notion at the time was that it’s easier and less frustrating to do so. Fortunately, we worked through most of these problems with a combination of open discussion, pair programming and pull requests.
Nevertheless, the notion prevails amongst some that all of this was an unnecessary change introduced because it’s new and shiny. The sentiment is largely that, while yes, there are beneficial features that Kotlin introduced to the code, Java is technically capable of being as immutable and null-safe as Kotlin through Lombok, Value Immutable and programming best practices. On top of that, the increased frequency of Java updates suggests that the best Kotlin features will be assimilated and the need for Kotlin will die off in a few years anyway.
It’s been a fun ride advocating for Kotlin at FREE NOW. While I personally remain convinced that Kotlin will continue to grow in popularity and feature-scope, it’s important to remember that introducing a language is a team decision. Had we decided during the sales pitch that Kotlin isn’t the right fit for our team, then that would have been okay too.
Would you like to work in a team like mine? Check out roles available in our tech hubs in Hamburg, Barcelona, Berlin and in all of our locations across Europe here.