Bus factor

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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,[1] 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.


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,[2] itself an evolution of the work published in the first book of the Pattern Languages of Program Design series in 1995,[3] 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.[4] The term had become commonplace in business management by 1998[citation needed] and was used[clarification needed] in mental health in the same year.[5] It was seen in software engineering papers in Association for Computing Machinery and Information Systems Frontiers by 1999,[citation needed] in engineering by 2003,[6] and the Debian project in 2005.[7]

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.[8]

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.[9][10]

Implications in business[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.[11]

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.[12] 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[edit]

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 (July 26, 2004). Organizational patterns of agile software development. Wiley. 
  3. ^ Coplien, James; Schmidt, Douglas (May 12, 1995). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley. 
  4. ^ Coplien, James (August 4, 1994), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished. 
  5. ^ 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. 
  6. ^ Redmond, Matthew C.; Newton, Paul (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF). 
  7. ^ Reinholdtsen, Petter (November 11, 2005). "Re: Resignation and uploads" (Mailing list). 
  8. ^ McLay, Michael (June 29, 1994). "If Guido was hit by a bus?" (Mailing list). 
  9. ^ Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (September 10, 2015). "What is the Truck Factor of popular GitHub applications? A first assessment.". PeerJ Preprints. 
  10. ^ 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:1604.06766free to read 
  11. ^ 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?"
  12. ^ Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley. 
  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]