How to build a great mobile application in a project… that has already been spent several times before you

But it was by no means zero. At the time of my arrival, there was already a well-established Enterprise architecture, some kind of infra, “almost” ready-made mobile applications for Android and iOS, remnants of the former team and missed deadlines. It turned out that the “Next Gen” application is not being developed for the first time, there were attempts before, and they all failed. Many engineers and managers who were involved in the project from the very beginning have long since left.

And then the realization came that this would be one of the most difficult and exciting projects in my (at that time 7-year) career as a mobile development lead …

Chapter 1

It was August in the yard, it was a rather spacious and beautiful office in the center of Moscow, I had just signed documents in the personnel department and immediately went to a working meeting with my new colleagues (by the way, a wonderful management team gathered!). Like me, everyone already had a lot of experience in financial institutions: blue ones, green ones, and many others. And, like me, all the guys had just joined the organization.

Our first task is to figure out what was done by the previous team, what are the problems. The next one is to propose your roadmap for the development and release of a new mobile application.

Hereinafter, I will describe my “mobile” part, but I will also periodically describe the context, tasks and results of the work of the entire management team, since mobile application development does not live in a vacuum: it depends on and is supported by the results of the work of other teams whose contribution to the overall I don’t want to underestimate the matter.

What happened in terms of technology?

There were current mobile apps on Android and iOS in the stores with extremely low ratings and a la “early 2010s” look and feel, which were developed by outsourcing guys. These applications needed to be replaced with new ones as soon as possible.
Almost ready apps for Android and iOS
Android-e: Kotlin, Kotlin Coroutines, Clean Architecture, multi-module on Dagger 2, MVVM on Flow, own design system (on standard views, without compose)
On iOS: Swift, RxSwift, VIPER, multi-module, design system (standard, no SwiftUI)
Separate library for Backend Driven UI with kernel written in KMM
CI/CD was simple, but still (based on gitlab) and could be developed
There were almost no unit tests
Modern microservice architecture, there are utility services

In fact, the picture seemed at least not bad. Theoretically, everything is in place, you just need to develop. The selected technology stack and division into modules made it possible to divide applications into “responsibility areas” and distribute them to product teams when they appear.

So, what was the organizational structure?

There were no product teams as such
There was a department (already thinned) for iOS and Android mobile development within our department
The department had departments of testing and system analytics
Infrastructure and devops, as well as regression testing, were outside the department and had to be negotiated with separately.

Yes, it was the “good old” organizational structure of the “developed waterfall” era. In the organization, as I understand it, the processes of dividing into business streams had just started, but at that time it looked like this:

And the worst part: there was no “demo”. Heads of business streams did not hold smartphones with new applications in their hands and did not have information in what quality their features come out and how they look.

Perhaps this was the reason for the failure of the previous team, as we thought then?

The decision was made to hold a first public demo to show our management and business stream management the current state of mobile applications.

And we did it. With one caveat. We just showed the apps in the worst possible light. That everything is bad: the design is ugly, the backend is slow and not the first time.

We criticized everything we could reach: the work of the stands, the design, that the application has a lot of defects, unstable backing, organizational structure.

We felt like revolutionaries, we wanted to expose all possible problems to everyone and offer optimal solutions.

But most of all, the work of the Backend Driven UI system and the policy of the architecture department were criticized, according to which, all front-end features should be developed as a priority as Backend Driven UI solutions based on WebView (React) or based on a form generator native for iOS and Android (KMM + platform implementation of UI components).

My colleagues suggested doing everything “purely native”, without backend driven to the maximum, only REST and separate code for iOS and Android, because there are more graphical capabilities, higher performance. Eventually it turned into almost like a slogan.

And that was the first and most important mistake.

Memory hole 1.

The goal was – to do everything “on the mind.” Of course, all the problems described above took place.

Quite quickly, the understanding came that it was necessary to create multifunctional product teams within streams that could independently display their products using the microservice platform, and the iOS and Android platforms.

There was just no problem with this. Management has allocated a large number of rates for hiring developers.

The top-level plan for the mobile part turned out as follows:

Start active recruitment
We create platform teams for iOS, Android, Mobile Backend Driven UI
Platform teams are centers of excellence, building shared services, unbording, and helping other teams
We create pilots of product Agile teams, where we gradually begin to plant mobile developers
Platform teams at first, in addition to developing architecture, common services and development tools, also point-wise help product teams in developing features while hiring
In 3 months we put the platform in order and make a new version of the design system
By this point, we are starting to put mobile developers into product teams and actually launch them
We actively implement agile practices in teams with two-week sprints running in parallel and with a large shared demo at the end
Run the release train (this was done by a separate release team)

As a result, we drew a big Roadmap for the year, marking important points of alpha, beta and production releases on them.

Everything would be fine, but let’s return to the error that was originally.

The Enterprise Architecture department initially urged all teams to use only the Backend Driven UI approach, regardless of whether it suits a particular team or not. Our team turned everything upside down: everything now needs to be written in the “native” + REST bundle, which is no better.

Indeed, the native form generator on Android and iOS took a long time to render screens, you really had to wait for several seconds. I asked the team that was responsible for the development of the native generator on Android and iOS to investigate what is at the root of the problem.

As it turned out, the developed Backend Driven UI protocol itself was quite multifunctional and supported multiple relationships between various UI components: for example, it was possible to set the display logic for components depending on the entered fields or the state of various sliders – especially important when filling out applications or questionnaires, for example, for credit. Just before displaying the screen, the engine calculated all these relationships, but initially it did not understand how many such connected components were and when it would finish processing them. Therefore, the developers simply inserted a fixed timeout of a few seconds for any screen, regardless of whether there are associated components there or not. It became clear that this is just an algorithmic problem and it can be solved, which was done in just a week by the guys. The screens started loading almost instantly, minus the occasional backend and testbed level issues.

When I returned to the management team with good news about our engine and with a proposal to leave all the functionality developed on the native form generator “as is”, only remake the UI components for new ones … I was asked not to spread it: everyone was already “charged” to completely redo all mobile application. In fact, it was necessary to redo all the features, all screens, add a lot of business logic, add REST requests and, accordingly, do a lot of work on the back side in order to support the necessary APIs.

Everyone was “charged”: the system analytics department was hastily and enthusiastically preparing new system analytics, and the design department was creating a new design system and listing and mapping screens to be redrawn.

I looked at the roadmap and realized that in less than a year it is very difficult to do it. What is the best option it would be to make a facelift and redo the first level of navigation. But the ship with the revolutionaries went a completely different way.

Besides same, all those few engineering guys, who stayed in the project and previously built and designed the entire system with Backend Driven UI, were simply dumbfounded by this situation. In fact, the results of their work were devalued and they were told that everything would now be new. Of course, after that, several really cool specialists left me who invested and believed in this project.

As for the approach, when we criticized everything and everyone, where we saw problems … Of course, other units began to treat us with at least apprehension, and at most – with hostility.

looking back

Remembering today all of the above, I would like to draw the following conclusions for myself:

There is no need to rush to redo everything, criticize everything and try to do it “like in big modern companies”, even if it seems obvious. The specialists who worked before you were guided by something the fastest and did a great and difficult job. Yes, such work may become irrelevant, or external factors may make their own adjustments. But in any case, this is a big job, you need to be able to learn from the experience of your predecessors, to understand what guided them.
In my experience, in the vast majority of cases, the formula “we will build a new World on the ruins of the old one” at least then turns into work on weekends and holidays, and at most – a failed project or extremely dissatisfied users. It is best to do a gradual facelift and refactoring, to create intermediate architectures from which it will be possible to move to the target ones with much less effort.
Teams should have a choice of which platform tools they use to achieve their goals. Product teams for platform teams are customers. If the client is dissatisfied with the platform and does not want to use it, then such a platform needs to be reviewed, get feedback from the teams and make a better version of the platform
Unfortunately or fortunately, most IT people in long-term planning take on more obligations and features for implementation than they should. Even if you think that you’ve done it 100 million times, think again – it’s better to promise less, but fulfill and be a hero, than to promise, to do the same volume as in the previous version, and be that same horn-horned creature 🙂

Looking ahead, it is Backend Driven UI that will save the situation in the development of these particular mobile applications, although they initially tried to refuse it to the maximum. But this is the topic of the next parts. And in the next one, I will try to tell you in detail about the recruitment system, the built processes in mobile teams and a little about back-end services, as well as a bunch of mistakes about micromanagement.

To be continued…