Back to main page

Quality is the Foundation for Long-Term Excellence

This series takes a deeper look at how our engineers build inclusive digital financial services. Learn more about how they address large-scale technical challenges at Tala.

By: Shon Shampain, Android Manager

Quality gets a bad rap sometimes because it isn’t a cutting-edge technology, per se. My hypothesis is that quality is the foundation for long-term excellence, and it’s the legacy that you leave for the next generation. Here at Tala, quality permeates every aspect of our business. As Dr. Benjamin Hardy famously said, “how you do anything is how you do everything.” At Tala, we are building a world-class Android architecture and a world-class Android team. Here’s a peek at how we laid the foundation for this effort.

It’s not obvious to many outside of the mobile ecosystem that a mobile app is actually a system that requires both periodic maintenance and, at times, major system upgrades. An example I use a lot is that a mobile app is similar to a car, with periodic maintenance being akin to oil changes and a major system upgrade being analogous to replacing a transmission. We’re all used to cars, so thinking you could drive a car eight years without an oil change would be odd. In a similar vein, if your car is otherwise running well after eight years and 350,000 miles, it wouldn’t be particularly surprising to learn the transmission is starting to fail and will need to be replaced soon.

At least one of the reasons many outside the mobile ecosystem are unaware of the upkeep requirements is based on a failure of the engineering group to properly communicate this. This lack of communication is widespread, and there are a lot of Android and iOS cars on the road that are 8 years old (or older) and still running on original fluids. The shoulders of our “information superhighway” are littered with vehicles, hood up and calling for help. I nearly fell off my chair to learn that at least two major players (undoubtedly, there are more) with major Android apps are still over 90% Java — the Android landscape switched to Kotlin beginning about six years ago. This is nothing less than technical negligence; kicking the technical debt can down the road, hoping that when things explode, you’ll have moved on. This is an issue we’re facing head-on at Tala.

The Urgency For Upgrades 

Preventative maintenance and general upgrades to a mobile app can generally be bucketed into two broad categories: a) third-party and OS upgrades and b) architectural upgrades.

By and large mobile apps are composite apps built with the help of many (50 or more for big apps) third-party libraries. If these libraries were released once and then they were done, there wouldn’t be any issues, but most libraries worth using are actively updated multiple times per year — as is Android OS. It is critical to be able to run your app on the latest version of both third-party libraries and Android OS, and there are penalties if you don’t. There is a time (this is not a metaphor, I mean explicitly there is a date on the calendar), probably more uncomfortably close than you would imagine, that any app will die from obsolescence unless properly cared for.

The more insidious upgrades, and the upgrades that most often get neglected, are the architectural upgrades. While OS and third-party libraries will have dates drawn in the sand when support is removed, such is not the case for architectural updates. It is wholly the responsibility of the mobile team to spearhead these upgrades and push them through to production.

Moving from Reactive to Proactive

A number of years ago, we in the Android community started hinting at functional programming and reactive patterns with EventBus (RIP — anyone remember Otto?). This ushered in the reactive programming era of RxJava and then later CoRoutines/Flows. It is unheard of for an app to not incorporate reactive patterns these days. This is a clear example of an emergent pattern becoming impressed upon the greater Android community and requiring itself to be adopted.

Other patterns that have occurred are the Java to Kotlin transition, the transition to a (debatably) industry-standard MVVM, and the probable move of Jetpack Compose to an industry standard. Each of these patterns necessitates an architectural change or, at the very least, a major refactor.

As standards are adopted, OS and third-party libraries are standardized and optimized around their usage. So the failure of an engineering team to, say, move from Java to Kotlin produces a cascading negative snowball of unwanted effects, which range from the app becoming less and less performant, fewer libraries supporting its functionality, and increased difficulty in hiring because the best swimmers in the pool have moved with the technology.

Building for the Future

As the Android Manager, I need to ensure I take good care of Tala’s seven million users. I need to make sure that I can deliver product functionality on time, but more long-term, I need to ensure that the platform will remain viable. I need to ensure that the app will run if we double or triple our DAUs. I need to be able to pivot and support the next new lending product that Tala innovates. I need to ensure that I can hire from a robust pool of talent.

Two key points are instructive in Tala’s ability to deliver quality improvement. First, we have a proactive approach defined for handling our issues; and second, we’ve gained leadership support for addressing quality (e.g., writing code that at first glance does not directly generate revenue). Our first core principle is to tackle the biggest, most foundational issues first, and to that point, here at Tala, we’ve moved to MVVM and will be moving to Compose. Our platform team “works around” the other developers by tactically choosing modules to refactor when they are not being otherwise heavily developed. In that way, we can upgrade our engine while still driving. 

Our engineering leads schedule team talks about new technologies and write white papers and documentation. This way, we integrate our quality as a team-wide expectation. Our leadership has authorized the developers outside of the platform team to contribute one day per week for quality efforts; because we all have skin in the game. In many ways, the ability of all of us (leadership, the platform leads, the product teams and the product developers) to move in the same direction with the same goal has made all the difference.

Further, we have a long-term plan (two years) detailing how we’ll move from foundational issues to finer points. Our next major chunk will be the application-specific architecture that sits upon the foundation. We aren’t planning much past that point because of the rate at which things change. We’ll just keep adapting to the prevailing environment.

Embracing the Quality Ethos  

In many ways, what we’re doing here in Android applies to what we’re doing more broadly at Tala. We’re iterating. We feel that anything worth doing is worth iterating. We’re not going to be able to plan this out perfectly, and we’re not looking to do so. In very simple terms, we’re taking our biggest problem and making it not our biggest problem. Lather. Rinse. Repeat. By continuing to build the quality muscle and addressing it bit by bit every day, we garner the long-term rewards that accrue with consistency. That is to say, we do awesome things, and over time, we do them quicker and better. The stated goal of the Android team is to build a world-class team and a world-class code base. We do this to support a Tala vision that unites and inspires us all.

This takes dedication and strategy. On an Android team, or any specialty team with limited ability to technically swap pieces with other teams, no one is going to tell you the most critical items that you have to care for. It’s your responsibility to ensure all the items no one else fully understands get taken care of. This requires a budget, and the allocation of funds is often contentious, especially when times are tight.  But in the end, it is the quality that you insist upon that will lay the foundation for everything you do.

Quality is indeed job #1.

Share this article now: