Bus factor is a software engineering term that measures the risk of a project losing critical knowledge when team members become unavailable. Specifically, it asks: “How many people would need to be hit by a bus before the project fails?” A bus factor of 1 means one person holds all the critical knowledge — if they disappear, the project is in serious trouble. A higher bus factor means knowledge is distributed more safely.
The term is deliberately dark humor. The “bus” is a metaphor for any sudden disappearance: quitting, illness, firing, or winning the lottery. The point is that many projects depend dangerously on a single person who never documents their work, never shares their knowledge, and never trains others.
Why It Matters
Bus factor is a measure of organizational fragility. Startups and small teams often have a bus factor of 1 because the founder wrote all the code, knows all the clients, and holds all the passwords. When that founder leaves — and they always do, eventually — the company faces a crisis.
Good engineering practices aim to increase bus factor: documentation, code reviews, pair programming, and cross-training. The goal is not to prepare for literal buses but to ensure that no single person is indispensable. Paradoxically, being irreplaceable is bad for both the project and the individual.
Examples
- Startup founder: Often the bus factor of 1 in early-stage companies.
- Legacy systems: Old software maintained by one retiring employee.
- Open source: Projects with one active maintainer face high bus factor risk.
Related Terms
- Knowledge silo, single point of failure
- Documentation, cross-training, redundancy
- Risk management, team dynamics