Bus Number – The GitHub plugin my coworkers asked me not to write
Engineering teams are revisiting the idea of “bus factor” tools that analyze version-control data to reveal how dependent a codebase is on specific developers. Proponents see value in identifying knowledge silos, improving maintainability, and assessing risk in both internal and open source projects, while critics warn that such metrics are easily gamed, dehumanizing, and prone to misuse for performance management or even hostile targeting. The exchange also surfaces broader tensions around fungibility vs. specialization, early‑stage speed vs. documentation, and whether metrics can ever capture the social dynamics that determine how teams cope when key people suddenly leave.
Bus factor concept & measurement
- Bus factor discussed as “how badly a project suffers if key people vanish,” with two formulations: number of critical people per file/system vs. number that must disappear before the project halts.
- Original paper’s method: a system is at serious risk if current authors collectively cover <50% of current files; “author” means someone with significant weighted contributions.
- Some argue the ideal is effectively zero unique-knowledge holders per area (everyone can cover everything); others say frontier/complex projects will inevitably have a bus factor of 1 in some domains.
Existing tools and real‑world use
- Multiple tools/products already track “knowledge distribution” or “knowledge islands” (e.g., for hotspots, single‑maintainer areas, handover planning).
- Large enterprises reportedly have internal dashboards for bus factor and related metrics.
- CPAN shows bus factor per project, with documented methodology.
- Some teams rejected similar tools (e.g., Pluralsight Flow) after seeing them misused for performance reviews.
Value vs. misuse and Goodhart’s Law
- Proponents: useful for spotting silos, planning handovers, enabling rotation, and protecting engineers from being trapped as “irreplaceable.”
- Critics: metrics quickly get gamed, become hiring/layoff inputs, or are used to dehumanize staff and enforce fungibility; Goodhart’s Law is a central concern.
- Some warn such tools could be weaponized externally (e.g., creating “hit lists” of critical OSS maintainers).
Fungibility, careers, and culture
- One view: high fungibility is healthy—knowledge hoarding is toxic, and “you can’t be promoted if you can’t be replaced.”
- Opposing view: strict fungibility wastes talent, adds process overhead, and may be rationally resisted by employees who don’t primarily optimize for company profit.
- Experiences shared where people were denied transfers due to being “unbackfillable,” then left; others note some orgs reward “critical” people highly.
Documentation, code review, and team practices
- Suggestions: organized documentation, runbooks, banning manual one‑person processes, and broad code review to reduce bus factor.
- Debate over whether code review is primarily compliance overhead or a key mechanism for knowledge sharing and catching issues beyond tests/linters.
- Some emphasize that good engineers intentionally lower their personal bus factor; value is in future potential, not past unique knowledge.
Startups vs. mature orgs
- Tension between “document everything” and early‑stage velocity.
- Some argue under‑documentation and extreme tech debt kill flexibility; others note that heavyweight process from big‑company culture can also sink startups.
Terminology: “bus” vs. “lottery” factor
- Several object to the morbid “bus” framing, preferring “lottery factor” or “attrition risk.”
- Others argue “bus factor” more accurately reflects real sudden losses (death, injury, legal/visa issues) vs. gradual exits like lottery wins.
Technical tangent: parallelism in git cloning
- Side discussion on
gnu parallelplusgit cloneover‑saturating CPUs due to nested parallelism (index-packthreads). - Proposed fixes: limit
pack.threads, pass per‑command config, or use a shared job server/global scheduler so only one layer parallelizes.