In business management, and especially in the field of software development, the bus factor is a measurement of the concentration of information in individual team members. It is also known as the lottery factor, truck factor, bus/truck number or lorry factor and connotes the number of team members that can be unexpectedly lost from a project ("hit by a bus", as it were) before the project collapses due to lack of knowledgeable or competent personnel.
But just try to understand that it was a pure accident; as much an accident as if he had been run over by a bus while crossing the street.
"Truck number" was already a recurring concept in the Organizational Patterns book published in 2004, itself an evolution of the work published in the first book of the Pattern Languages of Program Design series in 1995, which was the publication record of the first Pattern Languages of Programs conference in August 1994, where it was referenced in patterns including Solo Virtuoso. The term had become commonplace in business management by 1998 and was used[clarification needed] in mental health in the same year. It was seen in software engineering papers in Association for Computing Machinery and Information Systems Frontiers by 1999, in engineering by 2003, and the Debian project in 2005.
A recent study calculated the bus/truck factor of 133 popular GitHub projects. The results show that most of the systems have a small bus factor (65% have bus factor ≤ 2) and the value is greater than 10 for less than 10% of the systems.
Implications in business
In many software development projects, one goal is to share information in order to increase the bus factor to potentially the size of the entire team. A high bus factor is considered a good thing as it means that many individuals know enough to carry on and the project could still succeed even in very adverse events.
Team members do not necessarily have to get "hit by a bus" for the "bus factor" to apply - any number of events could occur in which a team member could be suddenly and substantially prevented from working on the project. This could include a person taking a new job, having a baby, or changing lifestyle.
A rare alternative definition for the bus factor defines the bus factor as the number of persons who are indispensable for the project. In other words, it is the number of persons who are a single point of failure. If using this definition, then a high bus factor is considered a bad thing (since the loss of any person included destroys the project), and zero is considered the ideal bus factor.
Increasing the bus factor
Several ways to increase the bus factor (thus making the project more resilient) have been proposed:
- Reduce complexity,
- Document all processes and keep that documentation up-to-date,
- Encourage cross-training.
- Bowler, Michael (May 15, 2005). "Truck Factor". Agile Advice.
- Coplien, James; Harrison, Neil (July 26, 2004). Organizational patterns of agile software development. Wiley.
- Coplien, James; Schmidt, Douglas (May 12, 1995). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley.
- Coplien, James (August 4, 1994), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished.
- Simon, Robert (May 17, 1998). The Mental Health Practitioner and the Law: A Comprehensive Handbook. Harvard University Press. p. 69. ISBN 0-674-69721-9.
- Redmond, Matthew C.; Newton, Paul (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF).
- Reinholdtsen, Petter (November 11, 2005). "Re: Resignation and uploads" (Mailing list).
- McLay, Michael (June 29, 1994). "If Guido was hit by a bus?" (Mailing list).
- Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (September 10, 2015). "What is the Truck Factor of popular GitHub applications? A first assessment.". PeerJ Preprints.
- Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016), "A Novel Approach for Estimating Truck Factors.", 24th IEEE International Conference on Program Comprehension (ICPC), arXiv:
- James Coplien, Pair Programming Illuminated. Quote: "How many or few would have to be hit by a truck (or quit) before the project is incapacitated?"
- Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley.
- Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams (2003). Extreme Programming Perspectives. Boston u. a.: Addison-Wesley. ISBN 0-201-77005-9.
- Laurie Williams; Robert Kessler (2002). Pair Programming Illuminated. Boston u. a.: Addison-Wesley. ISBN 0-201-74576-3.
- Kent Beck (2000). Extreme Programming. Das Manifest (in German). s. l.: Addison-Wesley. ISBN 3-8273-2139-5.
- How to protect your open source project from poisonous people, Ben Collins-Sussman, Brian W. Fitzpatrick, Google Tech Talks, January 25, 2007. A talk that includes (among other topics) discussion of bus factor and how to increase it