Bus Factor

Updated September 30, 20263 min read

In short

The bus factor is the smallest number of people who would have to leave a project suddenly before it stalls because nobody left knows its critical parts.

What is the bus factor?

The bus factor is the minimum number of team members who would have to disappear suddenly, hit by a bus in the grim original phrasing, before a project gets into serious trouble because nobody left understands a critical part of it. A bus factor of 1 means a single person holds knowledge that no one else has, which is a serious risk. Because the image is morbid, many people prefer the lottery factor, imagining that the person wins the lottery and quits.

Teams usually estimate it informally by asking, for each critical area such as deployment, billing, or the search service, who could fix it at 3 a.m. if it broke. If only one name comes up, that area has a bus factor of 1. Tools can also estimate it from version control history by finding files that were written almost entirely by one person. Ways to raise it include pair and mob programming, code reviews by different teammates, rotating tasks and on-call duty, writing runbooks and architecture notes, and storing shared credentials in a secrets manager instead of one person's head.

A low bus factor is like a restaurant where only one cook knows the recipe for the signature sauce: if that cook gets sick, the dish disappears from the menu. The idea matters for company teams, for open-source projects maintained by a single volunteer, and for anyone assessing the risk of depending on a small project.

The bus factor is often confused with a single point of failure. A single point of failure is usually technical, such as one server with no backup, while the bus factor is about people and knowledge; a bus factor of 1 is a human single point of failure. Raising the bus factor doesn't mean everyone must know everything, but that each critical area has at least two or three people who can work on it confidently.

Key takeaways

The bus factor counts how many people a project can lose before it stalls.
A bus factor of 1 means critical knowledge lives in one person's head.
Pairing, code review, rotation, and documentation raise it.
Version control history can reveal areas owned by a single author.
It is a knowledge risk, related to but different from a technical single point of failure.

Example

Checking who knows an area of the codebash

# Who made the commits that touched the billing code?
git shortlog --summary --numbered --no-merges -- src/billing/

#   412  Dana
#    17  Sam
#     3  Lee
# One person made about 95% of the changes: likely a bus factor of 1.

# Who has worked on it recently? (recent knowledge matters most)
git shortlog -sn --since="1 year ago" -- src/billing/

Readers ask

What is a good bus factor?

There is no universal number, but every critical area should have a bus factor of at least 2, and ideally 3 or more. For a whole project, the higher the better, as long as knowledge is shared deliberately rather than by accident.

What is the lottery factor?

The lottery factor is a friendlier name for the bus factor. It asks how many people could win the lottery and quit before the project stalls, which describes the same risk without the grim image.

How do you increase the bus factor?

Share knowledge on purpose: pair or mob program, have different people review and work on each area, rotate on-call duty, and keep short, up-to-date documentation for critical systems.