Code ownership has clear downsides. Even if a project is successful, having an owner gives you a single point of failure. Bad engineers also argue for ownership. Some engineers are so defensive about their code that they’re unwilling to make changes, and they don’t allow others to contribute changes either. Code is a means to an end, and some engineers get overly precious about their own code. All things considered, code ownership is still underrated.
The other end of the spectrum is a tragedy of the commons. Everyone freely modifies code written by others. You might even call this teamwork. Each file accumulates small changes that add complexity. This is expected. However, the problem is when there is no longer a clear owner of a given file. The code is not easy to modify because it doesn’t have a cohesive structure. There is little incentive for any individual engineer to fix it.
Just like you can’t necessarily make a programming project move faster by adding more engineers, you don’t necessarily reduce the bus factor by adding more eyes. What makes code easy or hard to update isn’t just the level of familiarity the engineers have with the code, but the complexity of this code. Code written by one or two people (in my experience) is the easiest code to update and maintain. Code without clear ownership and many editors is some of the trickiest code to understand.
It’s hard to refactor code unless you know enough about the problems it’s trying to solve. Code comments and tests help. However, complex features have complex interactions. These cannot be refactored unless you understand subtle details about how they work. Without this knowledge, a refactor can only be superficial. You can break up large functions into smaller ones, but architecturally, the control flow is just as confusing as it was before.
The business ultimately cares that new features can be added quickly, and that existing features work well, and are easy to maintain.
What doesn’t matter (relatively speaking):
- Code style / consistency / code linting / tabs vs. spaces
- More eyes on the code
What does matter:
- Code complexity
- API surface area
- Architectural clarity
- Code ownership / principal agent
I’m not here to tell you that code linting is bad. Linting is clearly good. A linted codebase is better than a non-linted one.
I’m also not saying that the routes.js file or that config files should always have owners. This kind of code is straightforward glue. There’s nothing special or unique about the changes that happen there.
