The Number Everyone Cites and Nobody Trusts
Ask an engineering leader what their bus factor is and you'll usually get one of three answers: a confident "two", a nervous "one, probably", or a long pause followed by "we should really figure that out".
What you almost never get is a useful conversation. Because bus factor — as it's commonly understood — is a single integer trying to summarise something that isn't a single integer. It collapses ownership, knowledge, review coverage, and maintenance capacity into one number, and in doing so it manages to be simultaneously alarming and uninformative.
We've looked at hundreds of repositories. The codebases with a "bus factor of 1" are often in better shape than the ones with a "bus factor of 4". The number isn't telling you what you think it's telling you.
What Bus Factor Actually Measures
The classic definition is the minimum number of contributors who would need to be hit by a bus before a project can no longer continue. In practice, almost everyone calculating it uses some variant of: the number of contributors responsible for the top X% of commits in the last Y months.
That formula has three problems.
It conflates committing with knowing. A contributor who has merged 200 small dependency-bump PRs is counted the same as one who designed the auth system. The commit graph shows activity, not understanding.
It treats the repo as a monolith. A bus factor of 3 across the whole repo is meaningless if all three people only touch the API layer and nobody understands the billing code. Risk is concentrated at the file and module level, not the repo level.
It ignores recoverability. A codebase with one expert author but excellent tests, clear documentation, and well-structured code is more resilient to that author leaving than a codebase with four contributors who all wrote different undocumented corners of a tangled monolith.
The number gives you a comforting sense of measurement without measuring the thing you actually care about: what happens if a specific person becomes unavailable?
A Better Framework: Three Layers of Knowledge Risk
Instead of a single number, look at knowledge risk across three layers. Each one tells you something the others don't.
Layer 1: File-Level Ownership Concentration
Forget the repo-wide bus factor. The question that matters is: for any given file, how many people have meaningfully touched it in the last six months?
"Meaningfully" matters. A one-line typo fix doesn't count. We define it as a contributor who has authored at least 20% of the lines currently in the file, or made a non-trivial change (more than ~10 lines) in the recent window.
Plot this distribution. You're looking for files where the number is 1. Those are your real risk hotspots — and they're almost never evenly distributed. In most codebases, 80% of the single-owner files cluster in two or three modules. That's where to focus.
Layer 2: Review Coverage on Critical Paths
The second-best protection against knowledge loss isn't having multiple authors — it's having multiple reviewers. A reviewer who approves a PR has, at minimum, read and reasoned about that change. They're a partial backup.
For each high-risk file, look at the PR review history. How many distinct reviewers have approved changes to it in the last six months? If the answer is one (or zero, in repos with optional reviews), the file isn't just owned by one person — it's only ever seen by one person. That's a different and worse situation.
This is also where review culture matters. A codebase where reviews are rubber-stamped doesn't get the benefit of review coverage even if the numbers look fine. Look at average comments-per-PR alongside reviewer count.
Layer 3: Recoverability Signals
The final layer is the one most teams skip: how hard would it be for someone new to take over a critical file?
This is harder to quantify but tractable through proxies:
- Test coverage on the file's behaviour. Tests are executable documentation. A file with 80% coverage is recoverable by a stranger; one with 5% coverage and a 1,200-line single function is not.
- Comment and documentation density. Not as a vanity metric, but as a signal of whether decisions are explained anywhere outside the original author's head.
- File size and complexity. A 200-line module with one owner is a manageable knowledge transfer. A 4,000-line one is a project.
- Time-since-last-touch. Counterintuitively, files that haven't been edited in a long time are lower risk if they're stable and well-tested. Code that hasn't needed to change is code that doesn't need someone to maintain it.
How to Read These Together
A file with one author, one reviewer, no tests, and 2,000 lines of churn in the last quarter is a genuine emergency. That's the situation worth losing sleep over.
A file with one author but three reviewers, good tests, and stable behaviour is fine. The author leaving would be inconvenient, not catastrophic.
A repo with a healthy "bus factor of 4" but where all four people only touch the same module — and nobody has reviewed the legacy payment processor in eighteen months — is a disaster waiting for a tax audit. The headline number reassures everyone right up until the moment it doesn't.
What to Actually Do About It
Audit by file, not by repo. Sort your files by single-author concentration and review your top 20. That's your real risk register. Most teams have never looked at this list and are surprised by what's on it.
Treat reviewer rotation as a deliberate practice. Rotating reviewers on critical paths costs almost nothing and produces a second person who has, at minimum, thought about the code. It's the cheapest knowledge-redundancy intervention available.
Invest in recoverability where you can't get redundancy. If a file genuinely has to be owned by one person — niche expertise, regulatory ownership, security-sensitive code — accept that and compensate with documentation, tests, and architecture decision records. Redundancy via written knowledge is real redundancy.
Stop quoting the number. When someone asks "what's our bus factor?", the honest answer is "that's the wrong question — let me show you the file-level breakdown". You'll have a better conversation, and you'll surface risks the headline number was hiding.
Knowledge risk is real, but it isn't a scalar. The teams that manage it well are the ones that stop trying to compress it into one.
See your repository's file-level ownership and review coverage with RepoShark →