Bus factor

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Will the project fail if this member is hit by the bus?

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


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.


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 (thus making the project more resilient) have been proposed:


  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. 
  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). 
  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. 
  11. ^ 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) 
  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. ^ 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