The more devs the merrier? (Part 2)
In the first part by Android dev Anthony Reboul, we talked about the technical improvements you can make to work with a bigger team of engineers. Let’s talk now about the team management and organization with the example of BlaBlaCar’s Android team.
3 — Team spirit and organization
We all know this: change can be painful!
Communicating between a group of engineers is not simple: new colleagues, different points of view, expertise and personalities… There is a lot to handle!
One of the biggest challenges for our team was to maintain good communication as we grew.
We decided to work on:
- Defining and writing clear coding and architecture rules
- A review process that allows us to be fast, efficient and maintain high quality in the app
- Determine a recurring moment for the team to communicate and improve its process
- Settle an onboarding policy and a set a positive team mood that allows each level of expertise and personality to work on the project
- Finding the right team organization within the company
Coding and Architecture rules
The more engineers you get, the more technical opinions you have!
There is an infinite way to write the same code, and each software engineer has his background.
The main benefit of writing coding rules is to make each code review easier and smooth. No more debates or long discussions. The code has to follow this rule that has been voted. Of course, anyone can challenge the rules or discuss adding new ones.
# Tip 1: Take time to define Code Style with your team.
56% of the code review comments are for code style convention (totally random statistics ;-))
You can save a lot of time by spending some editing the code style file of your project.
Preferences -> Editor -> Code Style
# Tip 2: Write a coding rule document and update it
It can be very useful to write all the coding conventions of your team. Be exhaustive and cover all the aspect of your code :
- PR Process
- Git Flow
- What is a good template for a PR
- Usage of Presenter in MVP
- Testing convention
- …
It will help at 3 aspects :
1- Newbies can have a very well defined framework and feel more confident to push their first pull requests and have it validated faster
2- As a checklist for PR to be sure to cover all the aspect of the code when you review it
3- The more engineers you get, the more debate you have. After hours of discussion, you will eventually find a good compromise for the best way to write this kind of code. It’s important to write it so that next time you will encounter this debate there will be an immediate answer to it.
#Tip 3: Debate and build an architecture guide of your code
Once again, it‘s first of all a matter of saving time by setting all the rules when you start coding a feature:
- What should my architecture be?
- Should I create a new module?
- How should I navigate from one feature to another?
- Should I do this logic in my activity? (No you shouldn’t!)
- …
But it’s more than that. Architecture is something in the long run, that evolves with years, testing and experience. And there is a high probability that you work on an architecture that was defined by someone else that isn’t on the team anymore, or that you define an architecture that someone you don’t know yet will follow.
This document should explain the logic and idea of the team at the present time and how it should evolve in the future. And how it handles legacy code from the past. This is why it should also include a legacy migration plan into it!
Don’t hesitate to put a lot of code examples into it. See some sample from our architecture guide :
Important: even if those rules are written, make them live! Iterate on it, debate it with your team whenever it’s relevant! it should be a guide, not a dictatorship!
A review process full of kindness and efficiency
As the team keeps growing, the code review becomes more and more important because there is a lot of code is changing every hour.
If we want to keep a high standard of quality for the app, we need to pay particular attention to the code review process.
Warning: This is a very critical step in your team organization:
- A too light process would let some bad quality code in production, and the team would not be aware of the evolution of a large part of the code
- A too restrictive process would be discouraging, would affect trust between the members of your team and set a very bad mood, and it would decrease the productivity of the team
#Tip 1: Find the best number of mandatory approval for your Merge Request :
If you are a team of 3 people, having 2 mandatory approvals to merge a request can feel a little too much (what happens if someone is busy or on holiday…) It represents a large amount of work.
On the other hand, with a growing team and some juniors in the team it can be dangerous to accept a Merge Request with just one approval.
In the BlaBlaCar’s Android team, we feel like 25 % is the magic number. One quarter of your team should have approved your work to be merged.
The wrong good idea: Considering the team was growing fast, and we had a lot of new people that didn’t know the legacy code and junior in the team, we decided to create two groups of reviewers :
-the optional reviewers and the mandatory reviewers. Basically you had to have one approval from a mandatory reviewer to be able to merge your Merge Request.
Why was it not a good idea? It created a difference of judgment between reviewers where you need trust ! And furthermore it results in disengagement from some reviewers (why should I review if my point of view is not taken into consideration). So we changed this.
#Tip 2: Use symbols to prioritize your reviews :
To help prioritize the review and being more efficient, we use a symbolic code. In order to differentiate a critical bug from a trivial one and accelerate the process review:
Recurring time to talk and continuous improvement
Because the team has grown very fast, a lot of things are evolving on a daily basis. Change in the architecture, in the process, in the scope of the project, in the way you work on a daily basis. That is why communication is very important! How do we communicate as an Android Team within Blablacar?
Every Tuesday, we have a recurring meeting called Chapter Android Meeting.
This idea of this meeting is to have a moment for the team to improve itself. Here we can talk about everything that affects our Android team and processes :
- Discussion about architecture
- How can we improve our coding review process?
- Our onboarding process
- What are the next technical developments we want to do?
- Presentation of POC / New libraries / Coding rules / An article you want to talk about
- Testing strategy
- Delivery process
- …
#Tip 1: This is not a BlaBlaCar meeting :
Mmm yes, technically it is, but ! This is a meeting to talk about Android, and not the current company projects. You should stick to how you can improve your team.
#Tip 2: Write everything, it will be useful later.
2 hours per week, with 10 engineers, is a lot of time. A lot of what you will talk about during this meeting is very valuable and will be useful later. A lot of debate occurs and a lot of important decisions are made. Designate a copywriter at the beginning of the meeting and write everything down. Each coding rule decision should be written clearly in the coding rule document, and same with the architecture document.
#Tip 3: Assign tasks
Each decision that starts with “we should try to do this…” should be transformed into a task assigned to someone of the team. At the beginning of the Chapter meeting, you can review the task of the last week to monitor the progress.
“Let me set the mood right“
The team at BlaBlaCar keeps growing and we are welcoming more and more software engineers.
You can encounter a lot of different personalities, depending on the level of experience and it is not always easy to make everyone work together.
For example, you all have heard of the imposter syndrome for software engineers.
How can they manage to work with those who have the opposite: huge software engineer ego! (in french)
To make everybody feel good and happy, we work on a lot of dimensions:
#Axis 1: recruit people with a good mindset
“If you want to go fast go alone, if you want to go far go together”
This is the philosophy of how we recruit people for our team, we want people that can fit in the team and help us go far!
In the company, your technical skills are as important as your mindset
#Axis 2: Onboarding process
Because when the team grows fast, a lot of people arrive in the project with no knowledge of the legacy code and team convention, it’s important to have an efficient onboarding process.
Take a lot of time explaining :
- How the company works
- What are the coding rules of the team
- What is the architecture
- What is the Git flow of the team
- Explain the release process
- What is the vision of the evolution of the application
Remember: “Share more Learn more“, this is one core value of BlaBlaCar, it’s important to give everybody in the team the same level of knowledge, to work efficiently as a team!
#Axis 3: Learn to communicate
Because there are a lot of people in the team, hence a lot of different personalities, it’s important to adapt your communication to the other ones.
Some tools are very useful :
- Process Communication Model: The art to adapt your communication to the personality you have in front of you
- Non Violent Communication: How to communicate more efficiently by expressing your needs instead of expressing reproaches.
#Axis 4: Team building
There is nothing more efficient to feel as a team, to go out of the office and do something cool together. This is once again important because the team at BlaBlaCar has grown very fast and we need to get to know each other better !
How BlaBlaCar organization enable bigger development teams
Squad + Chapter organization
As we are a bigger tech team (not only on Android, but on every front team, iOS, Web and also backend) it’s not always easy to synchronize everybody. Let’s imagine meetings with 40 people in the room…
That is why BlaBlaCar decided to group people from each tech team into Squads.
“A Squad regroups a team of multiple competences (tech / product / design / qa..) and the scope of the squad is restricted to a part of the customer journey (the search / the booking …)”
So the same way our architecture enables us to work on a different part of the code together without any pain point, the squad organization enable us to work on different features without conflict!
There are 5 squads inside BlaBlaCar, and we feel it’s important to keep 2 people of each front technology inside each squad to be able to take the decision together. This is why we aim to be an Android team of 10 people.
Important Tip: Don’t colocalize your team by Squad / colocalize them by Chapter
Yes, this is counter-intuitive!
But if you think about it, as an Android engineer, 90% of your day time is spent writing Android code, thus it’s more convenient to sit close to your Android colleague, than your Product colleague.
It’s also easier to talk on slack about a product issue than a coding issue.
And finally, you will work on a specific scope within your squad, and it’s important to keep abound with your chapter colleagues to have a technical consistency.
Wrap up
“You never change things by fighting the existing reality.
To change something, build a new model that makes the existing model obsolete.”
― Buckminster Fuller
What we learned during this journey is that we needed to reinvent ourselves, our model, our way of working to adapt to this new team size.
We needed a new architecture (modularization + clean architecture) to be able to work together on the same code, clear coding rules and processes to work efficiently. Organize ourselves as a team and work on our communication.
We also had to split our scope and responsibility to adapt to our size and company need, then we shifted to Squad organization. We then worked on our way to keep consistency as a team, a continuous improvement and a fun team spirit!
This is a work in progress, and you have to keep in mind that this should always be improved on a daily basis!
