Bus factor
The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, from the phrase "in case they get hit by a bus". It is also known as the lottery factor, truck factor,[1] bus/truck number or lorry factor
Contents
Definition[edit]
The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.
The expression "hit by a bus" describes a person either dying or more generally disappearing suddenly from the project. It is used to describe hypothetical future disappearances in a lightly humorous way. 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 or life status.
For instance, say a team of 30 people produces bread in three necessary steps: mixing ingredients, kneading the dough, and baking. 10 people know how to mix ingredients, all 30 people know how to knead the dough, and 5 people know how to bake. If all 5 people who know how to bake disappear, then the team can not produce bread, so the team's bus factor is 5.
A rare alternative definition for the bus factor defines the bus factor as the number of people who are indispensable for the project.[2] In other words, it is the number of people 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.
History[edit]
In 1907, Joseph Conrad wrote in The Secret Agent:
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,[3] itself an evolution of the work published in the first book of the Pattern Languages of Program Design series in 1995,[4] 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.[5] The term had become commonplace in business management by 1998[citation needed] and was used[clarification needed] in mental health in the same year.[6] It was seen in software engineering papers in Association for Computing Machinery and Information Systems Frontiers by 1999,[citation needed] in engineering by 2003,[7] and the Debian project in 2005.[8]
An early instance of this sort of query was when Michael McLay publicly asked, in 1994, what would happen to the Python language if Guido van Rossum were hit by a bus.[9]
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.[10][11]
The term is mostly used in business management, and especially in the field of software development.
Increasing the bus factor[edit]
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.[12]
Several ways to increase the bus factor have been proposed:
- Reduce complexity,[13]
- Document all processes and keep that documentation up-to-date,[13]
- Encourage cross-training.[13]
References[edit]
- ^ Bowler, Michael (May 15, 2005). "Truck Factor". Agile Advice.
- ^ Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley.
- ^ 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." (PDF), 24th IEEE International Conference on Program Comprehension (ICPC)
- ^ 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?"
- ^ a b c https://eight2late.wordpress.com/2008/09/03/increasing-your-teams-bus-factor/
Further reading[edit]
- 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.
External links[edit]
- Poisonous People, a talk that includes (among other topics) discussion of bus factor and how to increase it
