Owning Your Code

Code ownership. Good or Bad? It must be good because github has a CODEOWNERS file, and we have `METADATA.yaml`, right?

Like everything else, the answer is, it depends. In this case it depends on what you mean by code ownership. Because code ownership can mean different things to different people. In this case I'm not talking about who owns the intellectual property. I'm talking about the responsibility for code. Not just writing, but maintaining and extending it.

There are a handful of models to choose from. The simplest is strong individual ownership. For any given piece of code (application, library, module, service, etc.) there is exactly one person who owns the code and is solely responsible for making changes. That works. Clarity is always good, and you always know who's on the hook to make something happen. But it's less than ideal when you actually want things to happen. Especially if there is more work than the designated individual can do. That person becomes a bottleneck.

Another option is team or small group ownership. In complex systems this brings the benefit of reducing cognitive load while mostly removing the bottleneck(s) of individual ownership. If you're not part of the team you just make the function/network call and assume it's going to work. You don't know or care what's on the other end. You just do your day job and throw problems/issues over the wall and the team will pick them up and deal with them. It does make your job easier, and, because there can be multiple people working on the other side of the wall it is much more scalable than individual ownership. But the team on the other side of the wall isn't infinitely growing, and you're probably not the only one throwing things over it, so when your issue is dealt with is still pretty undetermined. There's still a bottleneck, but it's not as bad as it was.

Then there's collective ownership. Everyone owns everything. Have a problem? Just fix it. Don't like the way something works? Fix it. Need new functionality? Add it. After all, we're in a monorepo, so it's easy and it solves your needs. Perfect. Or not. Everyone owns everything is just another way of saying no one owns anything. That's anarchy, and we certainly don't want that.

Personally I'd like to see a modified version of team ownership. Reducing cognitive load is important, so I strive for that. And complex systems are just that, complex. Unless you've been thinking about something deeply for a long time there are almost certainly strange interactions and emergent behavior in a system you need to be aware of when making changes. And the only way to get those insights is through experience. So team ownership, as in responsibility for how the sub-system fits into the greater whole, makes a lot of sense. The team knows the sub-system, the tools, the customers, and the gotcha's. They're usually the right ones to make changes, so they should do it.

But not always. Sometimes they're busy. Sometimes your priority isn't theirs. Sometimes they don't understand you. In those cases the right thing to do is make the change yourself. Then make a request to the team to pull your changes in. A Pull Request if you will. Then the team can evaluate the PR, bringing their experience and plans to the evaluation, and then accept the change or make suggestions about how it can be improved. And they need to do that quickly. They might even iterate directly with the author of the PR to make sure it meets even more needs than the author had originally intended. And that's good for everyone.

Or, in other words, we're all responsible for getting our own work done, and sometimes that means making changes to parts of the codebase we don't normally work in. And in those situations we're all responsible for working with the experts in that area to make the right changes, not just the changes that benefit us, regardless of the cost to others.