How to Find the Bus Factor in Your Codebase

Bus factor is the number of people who would have to disappear before a part of your codebase became unmaintainable. If one engineer wrote the entire payments system, understands it alone, and is the only one who has touched it in two years, your bus factor for payments is one. That is a business risk hiding inside a technical metric. When that person leaves, gets sick, or goes on vacation during an incident, you are staring at code nobody living understands, in the exact moment you most need to change it. Knowledge concentration is a form of debt, and it is measurable straight from your version control history if you know what to look for.

Why bus factor is a real risk, not a cliche

People joke about the bus factor, but I have watched it bite hard. A departing engineer takes with them not just the code, which stays, but the context: why it was built that way, what the weird conditional guards against, which parts are load-bearing and which are vestigial. The code without the context is nearly as opaque as no code at all, which is the same problem I described with inherited legacy code in how to audit a codebase you inherited. A low bus factor means you are one resignation away from turning an active part of your system into legacy code you own but do not understand.

For a solo operator running a portfolio, this hits differently. I am the bus factor for a lot of things, which is a real constraint I plan around rather than pretend away. But even inside a team, concentration is invisible until it is a crisis. The point of measuring it is to convert an invisible risk into a managed one.

How to measure knowledge concentration from git

Your version control history is a record of who knows what. You can read concentration out of it.

Authorship distribution per module. For each file or directory, what share of the changes came from a single author? A module where one person authored 90 percent of the commits is a bus-factor-one module, regardless of how many people are nominally on the team.

Recency of second-owner activity. It is not enough that a second person touched a file once, years ago. Has anyone other than the primary author changed it recently enough to still understand it? Stale second ownership is barely better than none.

Concentration overlaid on importance. A bus factor of one on a throwaway script is fine. A bus factor of one on a high-churn, high-coupling core module is a five-alarm risk. You weight concentration by how central the code is, using the same coupling and churn signals I cover in coupling metrics that predict real pain.

A tool like ReformCode computes ownership concentration across the repo and overlays it on the parts that actually matter, so you get a ranked list of "critical code that exactly one person understands" instead of a raw authorship table you have to interpret by hand. The ranking is what makes it actionable.

What to do about the hotspots

Once you can see the concentration, you spread it deliberately. You do not have to fix every bus-factor-one file. You fix the ones that are both concentrated and important.

Pair and review across the boundary. Get a second person into the critical module through code review, pairing, or a deliberate feature assignment. The goal is a second person who has actually changed the code recently, not just read it once.

Document the why, not the what. The code says what it does. What leaves with the author is why. A short design note capturing the non-obvious decisions and the traps is worth more than line-by-line comments. This is the same reason I keep durable context around my own systems rather than trusting memory.

Reduce the code, not just spread the knowledge. Sometimes the reason one person owns a module is that it is a tangled mess only its author can navigate. Simplifying it lowers the bus factor by making it comprehensible to anyone, which is a better fix than assigning a second victim to memorize the mess.

Rotate on purpose. For the truly critical systems, rotate who does the maintenance work so knowledge stays fresh in more than one head. Concentration re-forms if you let the same person always own the same thing.

Watch it over time

Bus factor is not a one-time audit. It drifts. People leave, new code gets written by whoever is fastest, and concentration quietly re-forms around your best engineers precisely because they are your best engineers. Track ownership concentration on your critical modules as a standing metric, the same way you track drift or coupling, and act when a load-bearing part of the system slides to a single owner.

The uncomfortable version of this: the more capable an individual is, the more the team routes hard work to them, and the more concentrated your risk becomes on the person you can least afford to lose. Measuring bus factor is how you catch that pattern before it becomes the day someone gives notice and you realize a quarter of your revenue runs on code only they can read.