Forem: Jamie

The Bus Factor Is a Lie — and What to Measure Instead

Jamie — Wed, 29 Apr 2026 12:22:40 +0000

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 →

We tried to measure AI's actual impact on our codebase. Here's why it's so hard.

Jamie — Tue, 07 Apr 2026 10:11:54 +0000

Everyone's seen the stats. "55% faster." "40% more code." "3x productivity." They end up in pitch decks and team retrospectives, and nobody really questions them because the conclusion feels right -- AI tools do feel helpful when you're using them.

But when we actually tried to find those numbers in real commit histories and PR patterns, we hit a wall.

Not because AI isn't changing how people write code -- it clearly is. But because measuring how much, and whether it's actually good, turns out to be a genuinely messy problem.

The obvious metric is the wrong one

The first instinct is output. More commits, more PRs, more lines of code. And yes, those numbers do go up.

But so do some less flattering ones:

Average commit size grows -- more lines per commit, which correlates with harder-to-review changes
PR cycle times don't improve, and sometimes get worse -- reviewers are spending longer on more code written in a less familiar style
Commit message quality drops -- more "update logic", less actual context

None of this means AI is making things worse. It means raw output metrics don't capture what's actually happening.

The before/after problem

Comparing pre- and post-AI adoption sounds straightforward. In practice, you're also comparing different project phases, team compositions, architectural decisions, and a dozen other variables that moved at the same time. Almost every "AI made us X% faster" claim, when you look at the methodology, is comparing an enthusiastic adoption period against an uncontrolled baseline.

What you can actually observe

After looking at a lot of repositories, the measurable impacts fall into a few categories:

Code homogeneity increases. AI-assisted codebases tend to become more internally consistent -- the same patterns repeat. Good for cognitive load, but the same mistakes replicate everywhere too.

Review burden shifts. The bottleneck doesn't disappear, it moves. Code output goes up, but someone still has to review it. AI-generated code tends to look correct even when it isn't, which makes subtle bugs harder to catch.

Test coverage quietly degrades. AI-assisted PRs consistently ship proportionally less test code than production code. The feature lands fast, the tests get deferred.

The uncomfortable ones

Knowledge erosion. We've seen repositories where contributor breadth increases but contributor depth decreases. Bus factor metrics that look healthy, where none of the contributors could confidently explain the module without re-reading it. The metric looks fine. The codebase is fragile.

Architectural drift. AI-generated code is only as good as the context it had when generating. Over months, this creates "dialects" within the same repo -- different patterns for the same operations, because different sessions had different context.

The productivity paradox. More code, but not proportionally more capability. The codebase grows faster than the product does. AI accelerates accidental complexity because the cost of writing code drops while the cost of understanding and maintaining it stays constant.

What to actually track

If a single metric or simple before/after comparison won't cut it, here's what we think gives a more honest picture:

PR cycle time (not PR volume)
Review comment density (not approval speed)
Revert and hotfix rates (not commit counts)
Test-to-production code ratio over time
Contributor depth per module, not just breadth

And watch for: commit sizes trending upward without corresponding feature complexity, declining review thoroughness as volume increases, and the growing gap between code output and test coverage.

AI coding tools are genuinely useful -- we use them ourselves. But the rush to quantify impact has produced a lot of misleading numbers, and optimising for the wrong metrics leads you somewhere you don't want to be.

Curious whether others are tracking any of this, or whether most teams are still pointing at velocity and calling it done. What signals have you found actually tell you something meaningful?

How to Spot a Burning-Out Codebase Before It Burns Out Your Team

Jamie — Fri, 27 Mar 2026 11:45:38 +0000

The Codebase Knows First

It usually starts with a vague feeling. Standups feel heavier. Estimates keep slipping. Engineers who used to volunteer for hard problems are suddenly very interested in being assigned simple ones.

By the time it surfaces as a people problem — someone handing in notice, a team missing a milestone — the warning signs were already sitting quietly in the commit history, often for months.

Codebases don't burn out. But they accumulate the conditions that burn out the people working inside them. Learning to read those signals is one of the highest-leverage things an engineering manager can do.

The Codebase as a Team Health Mirror

A repository's activity patterns are a direct reflection of how a team is functioning. Commit cadence, PR review turnaround, contributor distribution — these aren't just engineering hygiene metrics. They're a record of how your team is spending its energy, who's carrying the load, and where friction is building.

The advantage of looking here is that it's objective and early. People are often reluctant to surface burnout or frustration until it's already critical. The repo doesn't have that filter.

5 Warning Signs to Watch

1. Sustained Commit Velocity Drop

A single slow week is noise. A four-week declining trend in commit frequency — especially when nothing obvious changed (no holidays, no planned focus sprint) — is a signal worth investigating.

This often means work has become harder, not less. Engineers are spending more time fighting existing complexity, debugging unclear ownership, or simply losing motivation to push things forward.

2. Bus Factor Creep

Pull up the contributor breakdown for your core repositories. If one person is responsible for 60% or more of recent commits, you have a bus factor problem — and potentially a burnout candidate.

High bus factor isn't just a knowledge-risk. It means one engineer is carrying disproportionate cognitive load, probably fielding most of the questions, and likely feeling increasingly isolated. When they leave or burn out, the knowledge goes with them.

3. Stale PR Pile-Up

Open PRs that sit untouched for a week or more are a sign that review culture has broken down. This usually happens for one of two reasons: reviewers are overwhelmed and deprioritising review work, or the codebase has become so complex that reviewing feels like too much to take on.

Either way, the PR queue becoming a graveyard is demoralising for the engineers opening them. It signals that their work isn't being seen.

4. Inactivity Spikes Around Specific Contributors

Look for individual contributors whose commit frequency suddenly drops — not to zero, but noticeably below their baseline. This is different from someone taking leave. It's the pattern of someone who hasn't quit but has mentally checked out.

These engineers are often still delivering on assigned work but have stopped taking initiative, stopped reviewing PRs proactively, stopped contributing outside of what's strictly required.

5. Shrinking Contributor Diversity Over Time

A healthy codebase sees contributions spread across the team. When you notice the same two or three names appearing on every recent commit — and others fading out — it's worth asking why.

Sometimes it's a natural consequence of specialisation. Often, it's a sign that the codebase has developed informal gatekeepers, or that the onboarding cost of contributing has become too high for newer team members to bother.

What To Do When You See These Signals

The goal isn't to fix the repository. The repository is just the evidence. The goal is to have better conversations, earlier.

Use the signals as a starting point, not a conclusion. "I noticed PR review times have been climbing over the past three weeks — what's making reviews feel hard right now?" is a much more productive conversation opener than a retrospective about why a deadline was missed.

Rotate ownership deliberately. If bus factor is creeping up, create explicit opportunities for knowledge transfer. Pair reviews, rotating on-call, architecture walkthroughs — not as a process exercise but because the team genuinely needs the coverage.

Cut scope when velocity drops. A sustained velocity drop rarely means people aren't working hard enough. It usually means the work itself has become harder than planned. The answer is almost never to push harder — it's to remove friction, defer non-critical work, or acknowledge that the timeline needs to change.

The engineers on your team will tell you when they're struggling, eventually. The codebase will tell you sooner.

I'm building RepoShark to surface exactly these kinds of signals automatically from your repositories. If you're an engineering leader who wants earlier visibility into codebase health, I'd love to hear from you.