Buscar

How we rewrote a 4-year-old mobile app in 6 months

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 11 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 11 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 11 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

How we rewrote a 4-year-old mobile
app in 6 months
Half a year later and after lots of plannings, retros, design reviews,
checkpoints and other tons of meetings. Now I can take the time to
write down how was the entire process, what we learned on the way
and a few re�ections from the product side of this project.
Who we are?
Passei Direto is an student network with over 15 million students
sharing study resources, course notes, test preps, homework help and
more. 
Users can access our product through the website or the mobile app
(Android / iOS)
Why rewrite the apps?
Our mobile team had only two developers, one for iOS and another for
Android. That means, every time we were going to build a feature, we
had two di�erent products to deal with (Androidd & iOS). Besides that,
features on our website were being shipped way faster.
At the end with this situation repeating for a while we had:
Gustavo Costa
Jan 15 · 12 min read
The apps didn’t have the same features as in our website and even
the look and feel was out of date. In addition, our Android and iOS
app also had signi�cantly di�erences between themselves.
The constant feeling of “…Mobile is slow / This feature will be
shipped later in mobile / We can think about this in mobile
later…”, although it was a fact, it was detrimental to the team’s
self-esteem.
Both iOS and Android projects were in need of lots of refactorings.
It was di�cult to have time for technical debt without slowing
down the pace even more. Balancing tech debt, bugs,
improvements and features was a big problem.
Re-work due lack of alignment between mobile and website.
So we started to give a look to a few other technologies and React
Native was the one that seemed more promising. One of the main
advantages, write one code that could be used to both apps...
Hands on React Native
None of us had experience with react before so, while still working with
the native apps, we researched more about it and developed a small
proof of concept. The idea was to learn and see if rewriting the app in
react would be possible and bring satisfactory results.
At the end, after reading articles, benchmarking and testing we didn’t
�nd any signi�cant reason to give up of the project (although we also
weren’t 100% sure react would be good and work as expected). The
problem was, when to start it?. It was easily going to take a lot of time
and we wouldn’t be able to maintain the native apps in parallel with the
react app.
Going all-in
•
•
•
•
The react project was in the paper but not sure when we would do it.
Then an opportunity has arisen with a bigger project we were starting
in the company. The back-end, API’s, databases and so on would be
refactored. Meanwhile, the web team would refactor their front-end so
they wouldn’t have important releases with new features for a while.
We were in June and all of these projects should be launched still in
that same year. All should be deployed together (due the back-end
changes and everything being attached).
At that time we had hired one more dev for mobile, so we had three
devs and our options were:
A: Only adapt our apps for the changes in the back-end and use
the rest of the time to speed up a little bit with the missing features
for both iOS and Android. 
We would be ready to launch in time with the other teams and
also deliver some new features but keeping the native
technologies.
B: Completely stop developing for the native apps and go all-in
react native. Rewrite the new app already considering the changes
in the back-end that would go live months later. 
It was a little risky because maybe we could not �nish the app in
time to launch and as I said before we weren’t 100% sure if
react would in fact be good.
C: Mix A+C, adapt our apps for the changes in the back-end and
use part of the time, not to build new features but to build the new
react app. 
We probably wouldn’t �nish the react app for complete until the
•
•
•
end of the year and we knew it would be a problem to continue
working on this the next year with all teams already done with
their refactorings.
We decided to calculate and assume the risk to go with the option B, go
all-in with react and make sure we had a new deploy coming out still
that year. Maintaining two native apps (iOS & Android) at the same
time wasn’t working well. Next I will describe how we planned and
managed the risk of the project.
Project planning and Risk management
Planning a project is an interactive process and it’s always in review but
there were a few things we did on the beginning that helped us to have
a good overview of what was to come.
Research and Analysis
On the beginning the devs spent a few days doing a deep research on
react native, trying to predict possible mistakes we could make, what
were the main challenges and how to avoid problems that could slow
down our progress.
Since no one of us had a good experience with the new technology, we
knew we would inevitably need to refactor the structure of the new app
a few times before doing it right, so it was good to use part of the time
on the beginning to study more and minimize possible errors.
Planning
Meanwhile, from the product side I was acting more as project manager
and product owner. While the team was busy with the researches I used
the time to scratch our planning and prepare for action.
First thing I had on my mind was prioritization. We had an app already
in production and the new app should have the same features and
functionalities, at least the most important, the ones who creates more
value to the user. So I mapped every screen we had on the app, every
single feature and put everything together in a presentation. To have a
good big picture I grouped them in modules.
Later, I looked individually to each module, screen, feature and took
notes of important details or characteristics that couldn’t be missed.
This was good because the rest of the team would also check it later
and we would need to discuss.
Prioritization and Estimatives
With the big picture ready it was time to estimate e�ort and prioritize.
We did a few meetings with the team, going for each screen and getting
a roughly estimative of its complexity. Each member exposed the e�ort
on that and its reason, then we compared with the other members and
if it was too di�erent from each other, we tried to �nd out why and get
in an agreement, always trying to think in a conservative way. In
addition to that, we also used one main feature as a basis for the other
estimations, this way we knew there was a fair balance among the
tasks. During this proccess, often checking to see if, in a high level view,
it was making sense.
The end result was a spreadsheet with a summary of the tasks, how
long it should take and the weeks until the end of the project. This
spreadsheet was updated basically everyday by me throughout the
entire project, so we could see what we were spending more time, what
was going faster and so on…
Overview of product specs that should be prioritized.
Risk management
In order to make sure we had the right estimative of e�ort and the most
important things delivered �rst. After having the �rst estimation done
we also added some “fat” of 30% to 50% trying to minimize chances of
missing deadlines and unexpected things that may could happen on the
way.
Macro and micro prioritization was another key initiative that helped
us to minimize the risk. Since we have everything split into modules, I
organized their order and this was the macro prioritization. We
ordered it in such a way to respect its dependences and getting �rst the
things that were more questionable, so if we had to face any big
problem, it would be better to face it earlier, instead of getting stuck
with this at the end. All the modules had important core features for
the usersso I had to have it in mind the need to going throughout every
module throughout the development proccess. 
The micro prioritization was inside each module, focusing to deliver
the main features of that speci�c module, the things that were the most
important to the user. If we reached a deadline, I would analyze what
was missing to �nish that module and skip those to the end of the
project if they weren’t essential or more important than what was to
come.
The thing is, each module is a mini-project. if we try to make it perfect,
we will stay forever working on this and at the end only one would be
Example of a spreadsheet to be prioritized and organized throughout the development process.
developed, that’s why we had to know when to stop working and keep
going.
The idea was to focus on the most important features of every module
�rst and later after having the core of the app working, we could work
on what was skipped. At the end this worked very well, if we hadn’t
used this approach we wouldn’t be able to �nish all modules.
Deliverables
We had only one deploy that would be at the end of the project and in
sync with the other teams. Instead of developing everything and use
the last few weeks to validate the entire app, we split our modules in
versions and continued to run our sprints as usual. Every single �ow or
action that had to take the user to a non-developed yet situation, we
would show a temporary 404 screen. So we knew that at the end of the
project no 404 screen should be on code anymore.
The �rst version we had app structure and login, this was developed
and validated. After validation we would consider this version as
completed (although after login a 404 screen was shown) with the
di�erence that it wasn’t deployed to the end user. It was just internally
for us to know that that module was done.
At the end of the project, Q&A shouldn’t have too much e�ort on
validating the entire �nal app since the validation occurred throughout
the development and the modules were tested already.
. . .
Learnings, challenges and unforeseen
In this section I will describe the learnings, challenges, unexpected
things that happened on the way and how we dealt with them.
The beginning was marked by two factors: Learning curve and
refactorings. Since none of us had experience with react before,
everything that we were building was learned shortly before, no matter
how hard we try to do the best we can the �rst time, usually we will �nd
out that wasn’t the best way. Therefore, the �rst weeks we had to
refactor some things quite often.
We also realized that due the learning curve and �rst-time build of
every component, the �rst features were taking more time to �nish,
which was going way over our deadline sometimes but later on we
could reuse them and that speeded things up a lot.
After two months or so we could see this re�ection on our schedule,
some features taking a lot of time, others taking less and it was starting
to get visible that we would need to speed up more to be able to �nish
in time. Fortunately we were able to shift one developer from another
team to help us in the mobile project. It was his �rst experience
working with mobile as well but no problem at all, the core of the
project was well built and in a matter of days he was able to understand
its structure and the technology.
A few weeks later the back-end project that was going on with the other
team was well advanced and we needed to adapt our services to the
new API. At this time we also had the opportunity to have one more
person joining the team and he could exclusively work with our API so
this helped us a lot.
To summarize:
Learning curve was visible and felt by everyone. First time to build
anything takes time while the other times are way faster, this was
also due the need to build anything from scratch initially, later the
reuse of components help a lot.
Refactoring more often on the beginning, especially with the app
structure which is critical and more di�cult to change later. At the
end things were clearly more smooth.
Foreseen the need of more members in the team to speed up
everything and delivery on time.
Launching the new app
•
•
•
Since we would deploy three big projects together we thought it could
be a little more di�cult to handle the bugs and errors post-launching
because we would have to identify what was causing what and the
source of the problem could be one of the three projects so we focused
in develop the new app also working for our old back-end. It means we
would be able to deploy before the other projects, detecting and solving
problems earlier.
We developed our new API supporting both situations, before and after
the deployment of the other projects.
Here’s the sequence of events:
Deploy of our API to old native apps. Our new API had a few
services that the new app would require so we deployed the API
�rst to see if we would have any problem or bug. 
We did have a few problems, so we solved and it was �ne!
Days later we deployed our new app only for 1% of the Android
users. Same as before, with this we could start getting the
problems and �xing them upfront before the deploy of the other
two big projects that the other teams were working on. 
Throughout the days we increased the % of Android users having
access to the new app. 
Few days before the deploy of all projects, we sent the iOS app to
apple review and also released it to everyone.
Finally the last deploy was together with the other teams. All the
services were shutdown, website and mobile stopped. Our users
1.
2.
3.
saw a screen informing about our maintenance. 
When the migration of data from the other teams were done,
everything went online again. 
Our mobile users now were seeing a screen asking them to update
the app since the old native app wouldn’t work anymore.
Of course we had some problems with speci�c devices and isolated
issues but nothing that couldn’t be �xed soon. I am very satis�ed with
the �nal result, for a project like this that was the �rst one for me and a
new technology for the whole team I think we did a good job.
I’m sure that not only me but everyone involved learned a ton and for
the next projects we will perform even more.
. . .
It’s important to emphasize that none of this would be possible without
the support and comprehension of my team members, our friends from
the other projects and the whole company itself. What we’ve done was
a real example of fellowship and teamwork, the challenges I mentioned
here were just a few of the many others we had during the projects.
Special thanks to Antônio Cláudio, Bruno Rodrigues, Carla Vitorino,
Ellis Carvalho, Pedro Diniz, Pedro Fernandes and Rubens Lopes 👏👏
👏
Now, check it out the �nal result on Google Play or App Store

Outros materiais