You have decided to launch the redesign of your Android mobile application (probably for one of These reasons) and you are in the process of launching the project. In this article, we have listed the 3 mistakes to avoid?.

Discard existing code

The temptation is great when you decide to do a redesign to start from scratch and redevelop the entire application. An opportunity to build a healthy foundation, to integrate the latest trendy technologies and to keep developers busy for many months! However, this solution, which is attractive at first glance, is not without its share of drawbacks:

• Starting from scratch, we strongly limit or even completely stop the development of the existing product.
• We also lose all the information contained in the existing code: numerous bug fixes, unwritten rules and behavior...
• There is a risk of not correcting the organizational problems that led to this situation: lack of documentation, lack of rigor in development, habit of prioritizing the release of new features at the expense of quality...
• Finally, there is a risk of exceeding the budget: in fact, knowing the product and the defects of the code base perfectly, there is a great risk for the team to underestimate the redesign time (by a factor much worse than for the usual estimates?)

In most cases, it's better to build on existing code. See also This great article for more details.

Not having an indicator to pilot the redesign

As we saw in the previous article, several reasons may have triggered this redesign. So there are elements of the application or code that we want to improve.

You should also keep in mind that the redesign can take place over a long period of time, probably several months. It is therefore interesting to set up indicators to monitor the progress of the redesign.

For example, we think:

• At incremental build time
• The delay in tickets due to architectural problems (and more generally speed)
• To the test coverage

These can also be indicators of progress in the redesign such as:

• The number of screens that have been redone
• The number of tickets made out of all the redesign tickets

It is especially interesting to verify that the redesign has generated the expected effects.

If you want to improve incremental build time, why not set up a test protocol to verify that performance is changing in the right direction? Good news is provided by the framework ! Likewise in the case of a UI redesign, we will closely follow the store rating and the NPS.

Not having a plan

Before engaging in the redesign of the entire application, it seems necessary to have an idea of the target architecture. The idea is also to list pain points related to the existing code base.

Ideally, we can prototype the new architecture on a new feature that is relatively independent of the existing one. We can then validate a target architecture on code that is directly useful to the product, and therefore by losing the minimum number of resources.

If there are no such features in the backlog, you can validate the architecture on an existing feature by transforming it into the target architecture.

Finally, in some cases where the target architecture is very far from the current code base, it is possible to create a POC, that is to say an application that is as empty as possible but where all the elements are there (screens, data module, domain module...). This makes it possible to create discussion within the team (everyone can propose patches, the aim being to align the team with a series of quality standards) and to completely overcome the compromises of the existing architecture.