How Code Ownership Impacts Dev Culture

Authors: Rosemary Chen, Hillman Chen

Over the years I’ve had the opportunity to work with various companies and numerous teams, each with its own cultural flair and flavor. Having gone through these experiences, I’ve developed a good sense of what I liked, what I disliked, what I think worked, and what didn’t. In this post, I’d like to discuss the differences between individual, collective, and Varo’s open-source style of code ownership.

Individual Code Ownership

When I was a junior developer having recently graduated college, I was oblivious to just how much engineering culture can vary from company to company, team to team.

At Ariba, I had joined a newly staffed team where one or two engineers were the front runners who built everything from the ground up. Since I had just moved into a full-time position from being an intern, I was eager to be challenged, to learn, and to contribute. They started me off with the easy tasks: writing unit tests, fixing simple bugs, and small features with the promise of the fun work coming in the following months. I did this for a long time and eventually felt frustrated and underutilized.

One day I expressed that I was thinking about quitting and Ariba quickly threw me into the deep end where I was swapped into yet another newly staffed team and became the sole maintainer of the team’s UI codebase. This was extraordinarily difficult to adjust to since I was going from 0 to 100 in a matter of weeks. Not only was I new to the ecosystem, but I also had little to no guidance, no peer to consult with, and a manager that didn’t care about my wellbeing. I was crashing and burning fast, so I had to learn to adapt even faster. Having experienced both sides as a maintainer and as a contributor, it was obvious to me that this system did not work well. To list a few, here are some things that I deeply disliked:

• Other team members felt that they were less responsible for problems, which often resulted in poor-quality code.
• The maintainer can be stretched very thin with work, meetings, and code reviews. Therefore, they may not be able to catch every detail.
• Feature work may have a longer turnaround time since the maintainer can become a bottleneck.
• Productivity may slow down when the maintainer leaves or goes on vacation.
• New ideas and code reviews can be highly subjective.
• It may be harder to accurately scope out work due to a lack of perspective and creativity that usually comes with team huddles.

Now, it may seem like a lost cause with all these negative aspects regarding individual code ownership, but there is a place where this style can shine:

• It is much easier to maintain code consistency since a single person dictates the standard.
• The maintainer knows exactly where everything is and what functionalities are implemented so it’s less likely for code to be duplicated.
• Large refactors can potentially be done quickly and without much overhead, since you are your own boss and you don’t need to consult with anyone.

Generally, I think this style of code ownership can work if the development team is extremely small and levels of experience are largely varied. But as the team grows and as the level of experience begins to even out, this style will naturally transition into a more collective code ownership style.

Collective Code Ownership

My job prior to joining Varo practiced collective code ownership. At its purest form, it’s simple and it works. Collective ownership gives the team a sense of responsibility because they are the sole owners and maintainers of the codebase. Anyone on the team is welcomed to make changes, and it becomes the entire team’s fault if the program fails. It is a collective effort to maintain the service and system.

At first glance, collective code ownership offers the following benefits:

• It is still relatively easy to establish and maintain code consistency within the team.
• Pressure and responsibilities are dispersed amongst a group of people so that team members can take vacation guilt-free.
• Services have a clear group of owners so that it is more efficient to hand off tasks to their corresponding teams.
• Refactoring a service is potentially much faster with less overhead since all team members already know the service.

However, despite all the benefits of collective code ownership, I’ve seen situations where it can fail:

• Speed of execution can be hindered by dependent teams because it can be up to the other team to prioritize dependent tasks.
• As the team and service grow, individuals may naturally start to specialize in certain areas. Certain tasks may be assigned to specific individuals who have prior knowledge of working in that component. As a result, work may start to feel stagnant due to a lack of variety in technologies.
• There is a potential for duplicate functionality done by different developers.
• In a fast-paced environment, upstream and downstream changes can occur frequently. It may be faster to fix issues yourself than to rely on other teams to respond.

How Varo is different

As far as I can tell, even after speaking with other colleagues, it seems like this is the industry standard for code ownership, but Varo disagrees. Here’s how Varo gracefully alleviates some of these pain points.

Here at Varo, we run on an open-source style of code ownership. Similar to collective code ownership, there are clear teams that are service owners. However, the main difference is that it promotes the idea of making the changes yourself regardless of how big or small the change is. In short, the open-source code ownership model can be described as the following:

• The service/codebase has a primary team responsible for any problems that may occur and can also recruit secondary team members when necessary.
• Only primary team members have permission to merge Merge Requests. All Merge Requests are to be reviewed and merged by the primary team.
• Code reviews are held to a strict standard so that the code quality can be maintained no matter who works on it.
• Any suggested changes must be conveyed to the primary team first.

With an open-source model, these are some of the elements that the Varo engineering culture encourages:

• Code dependency barriers are often the most common and frustrating reason most engineers face. When engineers are given the autonomy to make changes without having to rely on another team, this increases work motivation and excitement.
• Code reviews are an integral part of the development process. By maintaining a high-quality codebase, it’s easier for engineers to develop on, and more receptive to change.
• Generalist OR specialist, you choose!

On the other hand, it can be daunting to work on a service where you have no prior knowledge. Sometimes it may feel faster to delegate the task to the owning team rather than spending time to understand the service yourself. To mitigate this, engineers at Varo will make sure members are available to answer questions. As individuals begin getting comfortable with the service, the efficiency of this ownership model really pays off.

So far, I’ve been really enjoying this form of ownership model since it deeply aligns with my core value: growth. By erasing the guardrails from individual and collaborative ownership, I find that I am much more susceptible to learning. Having the opportunity to mess with the nuts and bolts of another service paints a clearer picture of the overall architecture. You learn from a wider audience of talented engineers by having exposure to other frameworks/practices that other teams implore within their work.