BAM customers and prospects have a lot of questions about application redesign, which is why I decided to start a series of articles on this topic.

Between bugs that accumulate and an aging UI, are you asking yourself the question of whether it is appropriate to start a redesign?

So here are some signs that a redesign is needed and what it can do for you. And to help less tech people take a step back on certain points, I suggest an analogy with the renovation of a home.

1. The code base is becoming difficult to maintain

The symptoms are well known: bugs and regressions follow one another, the speed decreases. The numerous “quality points” and “Unit Test Afternoon” are no longer enough to contain these signs. He is probably Time to undertake a real technical overhaul.

Just as when an aged home is spent more time maintaining it and if makeshift repairs do not last in time, it would be beneficial to renovate it more thoroughly and start again on a healthy basis (plumbing, electricity, etc.).

2. Are UI and UX no longer up to date?

Do you want to review the color theme, introduce or improve the Design System? It may be time to redesign the application in more depth. Start with a clean sheet of paper on design will allow you to modernize the application and to optimize the user journey. Very often this UI redesign is accompanied by a technical redesign as seen in the previous point.

We understand that it is easier to review the decoration and the habitability of a home during a thorough renovation than if you just apply a fresh coat of paint.

3. A new team takes over the project

When a new team gets a codebase they don't know, they often tend to denigrate existing code and want to start from scratch. It's probably not a good idea, but based on the problems identified we can trigger a gradual redesign of the application: make the application evolve towards a target architecture in a gradual manner, keeping the application code deployable at any time.

Likewise, the renovation of a property often takes place with a new owner, who is less able to accommodate the shortcomings of the layout of the existing one.

4. The technologies used are obsolete

Still stuck with the RxJava 1 or EventBus libraries? This type of library is often at the heart of it? At the heart of the application architecture, doing without it requires a redesign to a new, more current architecture.

It should also be noted that while some technologies are not obsolete at a moment, we know that they will become obsolete in the future. So, the days of Fragments And native views of Android are probably counted in the medium term, since google Now push the UI framework Jetpack Compose.

To continue the analogy with housing, it is better not to install a new oil-fired boiler during your renovation even if it is technically and legally still possible.

5. We want to modularize the code base

Driven byOptimizing compilation times and some features (Dynamic Features, Instant apps) Android application modularization is a hot topic in the Android world. It is a question of dividing the application into several modules with clearly defined dependency relationships. This increases compilation performance when developers are working on it, or makes it easier to increase team size by avoiding conflicts between several Feature Teams.

Attention, migrating an existing monolithic code base to a more modular architecture is not necessarily an easy task; it requires meeting numerous challenges (navigation, cyclical dependencies...) and cannot be improvised.

So, in the second article in this series, we will focus on properly preparing for the redesign of your application.