Why Code Ownership Sucks and You Should Never Work Somewhere That Practices It

Code ownership is one of those ideas that seems good on paper but falls apart disastrously in practice. The basic premise is that every part of a codebase should have a single "owner" who is responsible for writing, maintaining, and reviewing all changes to their little fiefdom. In theory, this provides clear boundaries and accountability. In reality, it creates knowledge silos, key person dependencies, and a host of other issues that hamper development velocity and system robustness.

As a professional full-stack developer with over 15 years of experience across multiple stacks and domains, I‘ve seen firsthand how damaging code ownership can be – not just for the codebase, but for individual developers and the organization as a whole. It‘s a misconception that the most elite tech companies hang onto this obsolete practice. In fact, many of the engineering cultures I admire most, from Stripe to Thoughtworks to GitLab, explicitly reject the code ownership model as an anti-pattern.

In this article, I‘ll lay out the many reasons why I believe code ownership sucks and why you should avoid it like the plague when choosing where to invest your talents. I‘ll draw on real-world examples, relevant statistics, and input from well-respected developers to build the case. Whether you‘re a grizzled veteran or just starting your programming career, I hope you‘ll come away with a newfound appreciation for the power of shared code bases and collaborative development.

Code Ownership is Shockingly Prevalent (And Hurts Software Quality)

You might be thinking, "Code ownership sounds like an antiquated notion, surely most modern tech companies have moved past it." I wish that were the case! But unfortunately, code ownership is still rampant in our industry. A 2021 survey of over 500 developers by Coding Sans found that 59% of respondents reported having code ownership (either individual or team-level) in their organization. That‘s a disturbingly high number in my view.

And the negative effects on software quality are well-documented. A study by Microsoft Research analyzed bugs across Microsoft‘s massive codebases and found that:

"Components with high ownership (more than 50% of the code written by one developer) had 3 times as many bugs per line of code than components with shared ownership."

3 times as many bugs for code that‘s closely held by one person! When you understand the perverse incentives and lack of oversight that come with code ownership, this isn‘t surprising.

Key Person Dependencies: A Horror Story

Code ownership‘s cozy theory quickly unravels when you see how it plays out for real software systems, especially as they scale. A tale from my time as a tech lead at a mid-sized startup paints the picture well.

We had an engineer, let‘s call him Dan, who was the sole owner of our business-critical payment processing system. Dan had written the bulk of the code from scratch and had unilateral say on all architectural decisions. The rest of the team had only a vague understanding of how it worked under the hood.

One day, Dan went on a long-awaited 3 week vacation to Europe. You can guess what happened next. Two days into his trip, the payment system started throwing exceptions every time a customer tried to upgrade their plan. Our team was getting paged left and right but no one knew how to debug the core issue. We had to resort to band-aid fixes while praying Dan would cut his vacation short to bail us out.

It was my worst nightmare as a tech lead – the stability of a core system hung by the thread of a single person, with no shared understanding or documentation to fall back on. Never again!

The Perils of a Siloed Perspective

Even if your "hero" sticks around, code ownership leads to myopic thinking and poor architectural choices over time. When all you see is your little slice of the system, it‘s easy to lose sight of the big picture and how your decisions affect other components. As Vivek Ravisankar, CEO of HackerRank, points out:

"Engineers who only work on a particular domain tend to develop tunnel vision. They often don‘t consider how their changes impact the overall architecture or other parts of the stack. This can lead to performance issues, API inconsistencies, and other problems as the system grows."

I‘ve seen this firsthand many times. A frontend engineer will make a change that inadvertently hammers the backend database with expensive queries. A machine learning specialist will productionize a model without considering the downstream effects on API payload size and latency. These disjointed decisions accumulate and gradually degrade system health.

In contrast, a full-stack perspective (enabled by shared code bases) leads to more holistic and considerate architectural choices. When you understand how the pieces fit together and regularly collaborate with specialists across the stack, you‘re better equipped to optimize for global goals rather than local ones.

Feedback Cycles Grind to a Crawl

Another casualty of code ownership is the pace of development, especially on larger teams. When every change has to be funneled through a single owner, iteration speed drops dramatically.

As GitLab‘s Remote Playbook explains:

"Code review becomes a bottleneck when knowledge is concentrated. If an owner is not available, a change cannot move forward. This is frustrating for developers and can lead to delays in shipping value to customers."

I‘ve felt this pain acutely as a full-stack engineer trying to rapidly prototype and iterate. There‘s nothing more defeating than having your momentum grind to a halt because you‘re blocked on a simple 2-line change pending review from an owner. Collective ownership is a game changer for maintaining fast feedback cycles.

Onboarding and Ramping Up Is Painful

Code ownership also makes onboarding new developers a nightmare. When ownership is localized, so too is all the context and institutional knowledge needed to be productive. New hires have to play an endless game of "find the owner" to get unblocked.

As one SpaceX engineer relates:

"Strict code ownership made ramping up on our codebase a slog. I constantly had to track down owners to get permission and background on the code I needed to change. It could take days to ship a simple bug fix."

With shared code, onboarding is much smoother. Documentation tends to be more comprehensive (since no one person holds all the context in their head) and developers are encouraged to explore and learn by jumping around the code. This more fluid structure enables new hires to start contributing meaningful changes quickly.

Brittle Code and Weak Tests

When code is jointly owned, there‘s a natural incentive to make it as understandable and maintainable as possible. After all, you never know who might need to change or debug it in the future (including your future self)! This leads to code that is more modular, better documented, and easier to reason about.

On the other hand, code ownership often leads to "pet" codebases that are overly complex and idiosyncratic, since the owner is the only one who needs to understand it. As long as it works, why refactor or simplify?

Lack of code sharing also tends to result in weaker testing. When an owner is the only one changing their code, it‘s tempting to cut corners on tests since they intimately know all the possible flows. Shared code encourages more defensive programming and comprehensive test coverage, since you can‘t assume everyone has the same context you do.

Heroes Get Burnt Out

Somewhat paradoxically, being the "hero" who owns a bunch of critical code can be exhausting and demoralizing. Sure, it might stroke your ego to be the go-to expert, but that wears thin quickly when you‘re getting paged at 2am to fix a bug or being pestered on your vacation to review code.

As one developer at a large ecommerce company confessed:

"I was the ‘hero‘ who owned all the cart and checkout code. At first it was nice to feel important, but it soon became a nightmare. I couldn‘t take time off without things breaking, and I was constantly stressed about knowledge transfer in case I got hit by a bus. I was heading straight for burnout."

Shared responsibility is a double-edged sword – it can diffuse glory, but it also diffuses pressure and stress. Collective ownership is more sustainable and humane in the long run.

How to Spot a Code Ownership Culture

By now I hope I‘ve convinced you that code ownership is an anti-pattern worth avoiding. But how can you spot it when evaluating a potential employer? Here are some questions I always ask to assess whether a culture is built around collaboration or silos:

1. How do you handle code reviews? Do you have owners who act as gatekeepers or is reviewing more distributed?
2. How often do developers change teams or projects? Is it easy to switch domains or are people stuck in the same area for years?
3. How do you handle knowledge sharing and documentation? Are there centralized knowledge bases or is tribal knowledge the norm?
4. How complete is your test coverage? Do you practice TDD or is testing more of an afterthought?
5. Can you give me an example of a major architectural change or refactoring that was done recently? Who led it and how did it go?

If you hear answers like "Jane has to approve every PR for the search service", "Most people stay on the same team for 2+ years", or "Tests are sparse in the older parts of the system", those are major red flags. Press for examples of cross-team collaboration, regular project rotation, and collective decision making.

Embrace Shared Ownership

As developers, we‘re the luckiest of professionals – we have incredible leverage to shape the software that increasingly runs the world. That‘s an exciting opportunity, but also a big responsibility. We owe it to ourselves, our teammates, and our end users to build the most robust and maintainable systems we can.

In my experience, shared code ownership is a key part of that mission. It promotes resilience, adaptability, and continuous learning. It frees us from the shackles of pigeonholed thinking and empowers us to make holistic architectural decisions. It makes onboarding smoother, development faster, and heroics less necessary.

If you‘re currently stuck in a code ownership culture, I feel for you. I‘ve been there and it‘s not fun. Consider having a candid conversation with your manager or team about shifting to a more collaborative model. Share resources like this article to help make your case. And if change seems unlikely, polish up that resume and seek out a culture of shared responsibility and growth.

Trust me, your future self will thank you. Happy coding!