Code quality and technical debt

Bus factor

Also known as Bus factor, Bus factor in software engineering

By WeavePublished 1 min read

Definition

The minimum number of people whose loss would put a project or critical area at serious operational risk.

What it means

Bus factor is an informal resilience signal based on how many people hold the knowledge needed to maintain or operate a component. A low value highlights concentration of expertise, weak documentation, or hidden operational dependencies. It should prompt knowledge sharing rather than serve as a judgment about individuals.

Example

A release pipeline can be repaired only by one engineer who knows its signing setup. The team documents the procedure, rehearses recovery, and trains a second owner.

Limitations

Contribution counts are imperfect proxies for knowledge. A person may appear inactive yet hold critical context, while several contributors may share only superficial familiarity. Use interviews, runbooks, and recovery exercises to validate the signal.

How to use the signal

Validate the apparent concentration with recovery exercises and interviews instead of inferring knowledge from commit counts alone.

Weave can show whether concentrated ownership coincides with review queues or blocked time. Weave does not infer a team’s bus factor reliably, so keep the assessment with managers and service owners.

How this relates to Weave

Weave can show whether concentrated ownership coincides with review queues or blocked time. Weave does not infer a team’s bus factor reliably, so keep the assessment with managers and service owners.

Explore Engineering intelligence

Sources and further reading

  1. SonarSource code metrics and analysis documentation