Code Owners at TheFork

How do we try to maintain our set of repositories/microservices at TheFork?

Introduction

In September, we have observed that we lose knowledge and ownership for different reasons:

• The switch from features teams to Shape Up in a domain organization. A single large team on several subjects. It was a test that allowed us to learn.
• The covid has gone through it, within parallel the classic turnover of tech companies.
• We have a complex microservices architecture

It has some consequences. The most annoying one remains the difficulty in homogenizing and maintaining all our work.

Our answer? Guidelines and ownership 🚀

Our goal is to copy open source way. Give back to the developers the power of mastering and maintaining their codebase while participating in exciting projects. The purpose is to simplify daily work in order to empower developers. We want to streamline their work for more creativity. We have been experimenting with it since September and hope to iterate on it soon to bring you a second article 🙂.

Why

We need to guarantee projects quality, homogeneity and monitoring. With some standard practices and decisions, we will ensure growth and scalability. This reflection aims to decrease our product’s time to market by limiting annoying work and technical debt during the delivery.

It seems easy to point out, but believe me, in a startup, scale-up, or a big company, handling coherent and efficient work is the most significant challenge.

What

To optimize ourselves, the first target would be our tech quality. We need to homogenize our decisions, projects, and architectures. An engineer must be able to work on any part efficiently. It’s a common need for any kind of job in a company.

Some points we need to catch:

Tech

• Harmonization (Decisions, Architecture, Dependencies, Security, Lint …)
• Projects onboarding efficiency
• Monitoring
• Refactors' anticipation to stay next-gen
• Documentation
• Responsibility & Expertise

Product

• Harmonization (Process, Shaping, Meetings)
• Documentation
• Responsibility & Expertise

How

We thought about shared guidelines and ownership. It’s just a deduction of open-source learning. Some people manage to achieve tones of worldwide projects without meetings 👀. Companies must learn from this impressive decentralized work.

To achieve this, there are:

• some principles in place (how they work)
• joint decisions (where they go)
• responsibilities divided across worldwide developers (the ownership)

All this together could answer our challenge and stimulate the company’s “synapses” — Yves Morieux 🤞

So we introduce the role of the code owner. A developer will be the owner of some repositories. It will be governed by standard rules put in place together. Therefore, they will become the leaders who will assume a part of our company’s work, the state, consistency and ambition.

Concretely:

1/ We have selected our important repositories (P0 P1).

2/ We have targeted that each of these will be owned by groups of 3–6 developers. It’s not for life, but it must be long term.

3/ We have set standard rules:

• Some templates, Readme, PR, Issues, Labels…
• More advanced one, update of dependencies, code coverage, some conventions…
• Others will be dedicated to programming languages, defined by the transverse guilds responsible for it

4/ We are working on an internal project to ensure they will respect those rules, Beacon. Like a CodeClimate, it runs through all our repositories and evaluates them (rules, KPIs…). If a test fails, it creates some issues. Homemade rather than external solution allows for customisation and multiple source aggregation.

5/ To work on these topics, we have freed up Friday afternoon (in the teams tested) during the bet cycles and the Shape Up Cool down.

Today, each code owner’s team in the test must try to have the best score on their repositories. The standard rules are discussed and implemented in Notion before being tested automatically by Beacon.

I am convinced that we are on the right track to increasing our CodeBase’s quality and taking back ownership. It’s a long-term effort that will allow us to regain comfort, creativity, and productivity. Indirectly it lightens daily life with a scalable and decentralized way of work. We just trying to get closer to OpenSource. It may not be perfect, but we will iterate and learn 🙃.

It is undoubtedly replicable in many other subjects in their way.

This is only the beginning and a try started last year, on a part of the devs, feel free to come and help us! 🤗