Having been in Android development since 2013, I can instantly recognize when a project has a problem. One of the biggest signs is the presence of Java, which often means management has outdated views, is focused on pushing new things (as opposed to writing good code), and most importantly, doesn’t understand their developers.
Personally, I reject all Android job offers with Java code (if the company has no intention to replace it). So, if you’re still clinging to Java in your Android projects, consider this your wake-up call.
Let’s take a look at some strategies you can implement to change your Android development process for the better.
I remember my first time using Jetpack Compose; it was such a revelation and a breeze to develop with. I was amazed by the straightforward data-to-UI flow. Although I had previously perfected using clean code principles in UI parts (XML), the fact that I now have to use Kotlin only for the whole app (without XML) was an extra bonus.
Having Java in an Android project means you have outdated code. That is something developers don’t want to deal with in the long run. In the Android ecosystem, a developer becomes outdated after six months if they aren’t using up-to-date technology. It happened to me once in 2018 and it was rough.
If you want to keep quality developers on the team, it’s time to stop torturing them and move toward creating a good development environment.
The best way to do this is to utilize current technologies, such as Kotlin (the language endorsed by Google for Android development since 2017), Jetpack Compose, and, the most widely used architecture, MVVM. This reduces developer turnover in the long run since it eliminates outdated and messy code, which can frustrate developers—many even quit over it.
A gradual transition to modern tools can create a more engaging and efficient coding environment, especially when it’s time to work on new projects.
Furthermore, it can reduce the time it takes to onboard developers into the team, cutting costs on hiring and education. For instance, a streamlined onboarding process can help onboard a professional freelancer in under three days. Anything above that NEEDS IMPROVEMENT!
However, it’s worth noting that it takes up to six months for new programmers to understand a large codebase, even though they might never touch some parts of it.
Sometimes, developers can stick to Java if there is pressure from upper management to cut corners. Since this approach focuses too much on short-term gains, the long-term negative impact can be significant.
When it comes to a project, cutting corners can lead to subpar code, reduced maintainability, and the accumulation of technical debt. The project can even require an expensive code rewrite if the bad practices continue too long. It’s okay to improve code, which Kotlin does, but full rewrites can be costly and slow the project down for a few months (sometimes up to a year).
Understandably, refactoring existing codebase might slow things down initially. However, the long-term effects, such as increased readability, maintainability, scalability, and testability, are worth it, especially if they lead to a stable application.
It’s up to project managers to foster a culture of quality and long-term thinking to avoid cutting corners. They should also push back on upper management and stakeholders whenever there is pressure to release new features. Often, the best argument is to have apps with fewer stable features rather than many unstable ones.
Java’s lack of modern features (e.g., concise syntax, null safety, coroutines, smart casts, and higher-order functions) makes it hard to implement contemporary coding practices and architectures efficiently. As with cutting corners, this also contributes to technical debt as developers rely on outdated paradigms.
By transforming the existing codebase from Kotlin to Java, it improves the code structure. This means less duplicated code, simpler designs, improved modularization, and fewer bugs. Furthermore, it makes it easier to align it with modern coding practices and architectures since it simplifies updating, scaling, and maintaining the code.
The initial time and resource investment might be high, but the long-term benefits far outweigh it and this is one of the biggest reasons why Kotlin is better than Java. This transformation needs code reviews, code refactoring, and in the most extreme cases, a full code rewrite.
Kotlin will make your developers more productive. For instance, they will write less boiler code, giving them more time to actually solve problems and deliver features quickly in your Android app. This level of efficiency can significantly reduce the development time—the app launches faster and revenue generation starts sooner.
Also, the conciseness and expressiveness of Kotlin (compared to Java’s verbosity) can make coding more enjoyable. Developers don’t need to stress about how different Kotlin is from Java. Kotlin’s interoperability with Java makes transitioning much smoother and reduces the learning curve.
So, on top of making developers more productive, it can positively impact their morale. If you factor in Kotlin’s support for current development practices, you can also attract top talent looking to work with cutting-edge technologies.
While Java has been reliable for Android development for a decade, the shift to Kotlin is necessary. Kotlin’s modern features lead to improved code quality, increased productivity, better app stability, boosted developer morale, and enhanced project maintainability.
Stakeholders and project managers should lead the transition by fostering a culture focused on code quality and developer experience with the right allocation of resources.