Ownership and Bus Factor

Understand who knows which parts of the code

Ownership and Bus Factor

The bus factor is one of those notorious rules in software engineering that sounds almost like a joke. It describes how many people on a team would need to be hit by a bus (or, more realistically, get sick, go on parental leave, or change jobs) before a project is in serious trouble.

I've worked on several projects where a single developer was the only person who truly understood critical parts of the system. When that person suddenly became unavailable(illness, a job change) the entire project was put at risk.

This is one of the main reasons I value pull requests and code reviews. Not primarily because they catch bugs, but because they spread knowledge. Knowledge silos, where one person exclusively owns critical code, are a major technical risk and often, a bit surprisingly, a cultural one as well.

I've seen how this can lead to unhealthy dynamics where individuals begin to feel indispensable and (un)intentionally use that position to their advantage. I've even found myself in that situation, developing a false sense of importance without realizing it at first. When I left my comfortable job and joined a new team, I got a much-needed reality check.

Why it matters

Ownership analysis shows who contributes to each part of your codebase. When one person owns 95% of the commits in a critical module, that's a knowledge silo and a major risk. If the bus factor is 1 or 2, you're vulnerable.

By mapping commits to authors, you can find these dangerous concentrations of knowledge. A healthy codebase has multiple people familiar with each important part, so no single departure cripples the team.

Cosmic Analogy

The visualization below shows two orbital systems representing different bus factor scenarios:

Fragile Orbit (Low Bus Factor): A single core represents a knowledge silo—one person holds critical system understanding. If they leave, the system becomes unstable.

Healthy Orbit (Higher Bus Factor): Knowledge is distributed across multiple clusters with shared ownership. Several people understand each area, creating redundancy. Green satellites indicate well-understood components with backup knowledge.

Cosmic analogy

Ownership and Bus Factor Visualization

How to Fix

Collaborative Development Practices

Mandate code reviews for all changes to ensure at least two people understand each change. We can't avoid the situation when pull requests are not rubber stamps, but it's still better than nothing.
Implement pair programming or mob programming sessions on critical, single-owner modules.
Assign secondary owners to critical modules. It's usually people who regularly review and contribute to that area.

Knowledge Sharing & Documentation

Create comprehensive documentation for high-risk, single-maintainer modules before knowledge is lost.
Schedule knowledge-sharing sessions where sole owners present their modules to the team.

Team Rotation & Onboarding

Rotate developers through different areas of the codebase to spread knowledge organically. That's good for product-oriented teams, but I'm not that sure about teams working on a project. These projects are usually more cost-sensitive.
Use onboarding as an opportunity to transfer knowledge by pairing new hires with domain experts.

Culture & Ownership Mindset

Encourage a collective ownership culture where team members feel empowered to work across boundaries.

Monitoring & Risk Management

Set up bus factor alerts that trigger when any module drops below a 2-person threshold.
Plan knowledge transfer activities before team members go on extended leave or transition roles.