Bus factor

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus." It is also known as the bread truck scenario, bus problem, beer truck scenario, lottery factor, truck factor,[1] bus/truck number, or lorry factor.

The concept is similar to the much older idea of key person risk, but considers the consequences of losing key technical experts, versus financial or managerial executives (who are theoretically replaceable at an insurable cost). Personnel must be both key and irreplaceable to contribute to the bus factor; losing a replaceable or non-key person would not result in a bus-factor effect.

The term was first applied to software development, where a team member might create critical components by crafting code that performs well, but which also is unavailable to other team members, such as work that was undocumented, never shared, encrypted, obfuscated or not published. Thus a key component would be effectively lost as a direct consequence of the absence of that team member, making the member key. If this component was key to the project's advancement, the project would stall.

Definition

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 darkly humorous way. Team members do not literally 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, going on parental leave, 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. Ten 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 cannot produce bread, so the team's bus factor is 5.

There is a rare alternative definition for the bus factor, namely: the number of people who are indispensable for the project.[2] In other words, it is the minimum 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

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 and was used 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, 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

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:

References
  1. Bowler, Michael (May 15, 2005). "Truck Factor". Agile Advice.
  2. Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley.
  3. Coplien, James; Harrison, Neil (July 26, 2004). Organizational patterns of agile software development. Wiley.
  4. Coplien, James; Schmidt, Douglas (May 12, 1995). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley. Bibcode:1995plpd.book.....V.
  5. Coplien, James (August 4, 1994), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished.
  6. 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.
  7. Redmond, Matthew C.; Newton, Paul (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF). Archived from the original (PDF) on 2012-03-12.
  8. Reinholdtsen, Petter (November 11, 2005). "Re: Resignation and uploads" (Mailing list).
  9. McLay, Michael (June 29, 1994). "If Guido was hit by a bus?" (Mailing list).
  10. Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (September 10, 2015). "What is the Truck Factor of popular GitHub applications? A first assessment". PeerJ Preprints. doi:10.7287/peerj.preprints.1233v3.
  11. Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016). "A novel approach for estimating Truck Factors". 2016 IEEE 24th International Conference on Program Comprehension (ICPC). pp. 1–10. arXiv:1604.06766v1. Bibcode:2016arXiv160406766A. doi:10.1109/ICPC.2016.7503718. ISBN 978-1-5090-1428-6. S2CID 19238548.
  12. 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?"
  13. "Increasing your team's bus factor". 2008-09-03.

Further reading
  • 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.CS1 maint: multiple names: authors list (link)
  • 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.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.