Don't make your teammates kill themselves

At Cabify we recently underwent an important rebranding. You can imagine what that meant: branding directives, design meetings, sketch iterations…

But, what does that mean from a developer team point of view? Well, let me tell you, it was quite a challenge.

Where were we?

In the Android team, our development workflow consists mainly of a customised gitflow-ish + pull request approach, following the common steps for each feature. In a happy scenario, the process is like this:

  • Create a new branch based in the develop one, where all the features begin and end.
  • Code the feature in that branch, splitting the evolution in small, atomic and meaningful commits that we are able to create.
  • Clean and polish the code to be presented to the rest of the team. Run all the tests and code analysis, seeking perfection.
  • Create the pull request explaining why this change was needed in the first place, how you did it and what the result was.
  • At least two members of the team act as the core code Cerberus and review the PR looking for tiny details (or not so tiny in some cases!) and validating the feature.

How does it fit into the workflow?

At this point, the team encountered a few dilemmas when we were preparing for the rebranding sprint:

  • We didn't want to treat it as a normal feature — this is an epic task.
  • What happens if the rebranding release date is pushed back and we have to publish a mandatory fix or whatever in the meantime?
  • So, could the complete rebranding fit in a single feature in order not contaminate the develop branch?
  • But… Do we want to review it as a single feature?

So after a couple of meetings, a few ideas and plenty of coffees, we decided how we were going to approach this feature. We would create a main rebranding branch, that would act as our develop branch for this matter. Small features, one for each screen or workflow would be based on the main rebranding branch and would merge into it.

This way we could review "small" pieces of code, iterative changes and it would be in a separate space from the core code, where we would follow our gitflow-ish workflow to fix bugs or create non-rebranding-related stuff. And when everything was ready to launch, we would just need to push the button.

Retrospective

Let's admit it, it hasn’t been all a bed of roses. We encountered a few problems along the way. We could have done an even better job and we could planned in a better way, that's for sure.

The rebranding meant reviewing all the screens and flows of the app, so why not do all those tiny related refactors we had in the backlog? Plus, replace all the multi-density resources with vector drawables. Oh, I almost forgot, and improve layout efficiency at the same time! Seems logical, right?

We wanted to clean our baby and all those points were necessary…

Well, maybe in some cases that's true, but I think we got in too deep in other ones, pushing the deadline back and back, and making it really hard to decide where to stop a refactor.

What we learnt?

I’d like to share some advice based on our experience with this rebranding.

  • Define the scope of the epic feature. What is needed and why? Keep that in mind during the whole process.
  • Draw some boundaries. Limit the level of the refactor you want to accomplish. Decide what’s important for the product and the team, and stick to that.
  • Live to fight another day. It is much better to make it simple. When you find yourself with enough energy and time, you can always go back and make it better. But you can't do it the other way around.
  • Divide and conquer. There is a direct relationship between the simplicity of the PR and the quality of the feedback your teammates can give you. Don’t make your teammates kill themselves with huge PRs.

I hope that our successes and mistakes can help you someday #CabifyPurple

Like what you read? Give Miguel Catalan Bañuls a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.