Bus factor

{{unref|section|date=April 2025}}

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. 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 cannot produce bread, so the team's bus factor is 5. A bus factor of one is a single point of failure.

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 to be hit by a bus.{{cite mailing list|last=McLay|first=Michael|title=If Guido was hit by a bus?|date=June 29, 1994|url=http://legacy.python.org/search/hypermail/python-1994q2/1040.html}}

"Truck number" was already a recurring concept in the Organizational Patterns book published in 2004,{{cite book|last1=Coplien|first1=James|last2=Harrison|first2=Neil|title=Organizational patterns of agile software development|date=July 26, 2004|publisher=Wiley}} itself an evolution of the work published in the first book of the Pattern Languages of Program Design series in 1995,{{cite book|last1=Coplien|first1=James|last2=Schmidt|first2=Douglas|title=Pattern Languages of Program Design|date=May 12, 1995|publisher=Addison Wesley|chapter=Chapter 13, A Generative Development-Process Pattern Language|bibcode=1995plpd.book.....V}} 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.{{citation|last=Coplien|first=James|title=Internal proceedings of PLoP 1994|place=Allerton Park, Illinois|date=August 4, 1994|publisher=unpublished.|chapter=A Generative Development-Process Pattern Language|url=https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/PLoPD1/section4|access-date=September 12, 2014|archive-date=September 12, 2014|archive-url=https://web.archive.org/web/20140912213259/https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/PLoPD1/section4|url-status=live}} The term was used{{clarify|date=August 2015}} in mental health in 1998.{{cite book|last=Simon|first=Robert|title=The Mental Health Practitioner and the Law: A Comprehensive Handbook|date=May 17, 1998|publisher=Harvard University Press|isbn=0-674-69721-9|page=69}} It was seen in engineering by 2003,{{cite web |url= http://proceedings.esri.com/library/userconf/proc03/p0559.pdf |title= Integrating GIS in the Engineering, Planning and Design Processes |first1= Matthew C. |last1= Redmond |first2= Paul |last2= Newton |year= 2003 |url-status= dead |archive-url= https://web.archive.org/web/20120312133941/http://proceedings.esri.com/library/userconf/proc03/p0559.pdf |archive-date= 2012-03-12 }} and the Debian project in 2005.{{cite mailing list|last=Reinholdtsen|first=Petter|title=Re: Resignation and uploads|date=November 11, 2005|url=https://lists.debian.org/debian-devel/2005/11/msg00801.html}}

Studies conducted in 2015 and 2016 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.{{cite journal|last1=Avelino|first1=Guilherme|last2=Valente|first2=Marco Tulio|last3=Hora|first3=Andre|title=What is the Truck Factor of popular GitHub applications? A first assessment.|journal=PeerJ Preprints|date=September 10, 2015|url=https://peerj.com/preprints/1233/|doi=10.7287/peerj.preprints.1233v3|doi-access=free|access-date=December 4, 2015|archive-date=December 8, 2015|archive-url=https://web.archive.org/web/20151208134101/https://peerj.com/preprints/1233/|url-status=live}}{{cite book |arxiv=1604.06766v1|doi=10.1109/ICPC.2016.7503718|isbn=978-1-5090-1428-6|bibcode=2016arXiv160406766A|chapter=A novel approach for estimating Truck Factors|title=2016 IEEE 24th International Conference on Program Comprehension (ICPC)|pages=1–10|year=2016|last1=Avelino|first1=Guilherme|last2=Passos|first2=Leonardo|last3=Hora|first3=Andre|last4=Valente|first4=Marco Tulio|s2cid=19238548}}

The term is mostly used in business management, and especially in the field of software development.{{Citation needed|date=July 2021}}

In many software development projects, one goal is to share information in order to improve the bus factor, potentially to the size of the entire team. A good bus factor means many individuals know enough to carry on and the project could still succeed even in very adverse events.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?"

Several ways to improve the bus factor have been proposed:

• Reduce complexity,{{Cite web|url = https://eight2late.wordpress.com/2008/09/03/increasing-your-teams-bus-factor/|title = Increasing your team's bus factor|date = 2008-09-03|access-date = 2015-12-04|archive-date = 2016-04-16|archive-url = https://web.archive.org/web/20160416081240/https://eight2late.wordpress.com/2008/09/03/increasing-your-teams-bus-factor/|url-status = live}}
• Document all processes and keep that documentation up-to-date,
• Encourage cross-training.

• Organizational memory

{{Reflist|30em}}

• {{cite book|title=Extreme Programming Perspectives|author=Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams|publisher = Addison-Wesley|location = Boston u. a.|year=2003|isbn=0-201-77005-9}}
• {{cite book|title=Pair Programming Illuminated|author=Laurie Williams, Robert Kessler|publisher=Addison-Wesley|location=Boston u. a.|year=2002|isbn=0-201-74576-3|url-access=registration|url=https://archive.org/details/pairprogrammingi0000will}}
• {{cite book|title = Extreme Programming. Das Manifest|author=Kent Beck|publisher= Addison-Wesley|location =s. l. |year=2000|isbn=3-8273-2139-5|language=de|author-link=Kent Beck}}

• [https://www.youtube.com/watch?v=Q52kFL8zVoM Poisonous People], a talk that includes (among other topics) discussion of bus factor and how to increase it
• [https://web.archive.org/web/20011113013913/http://segfault.org/story.phtml?mode=2&id=38b40d78-087dd360 "What If Linus Torvalds Gets Hit by a Bus?" - An Empirical Study], a humour piece

Category:Computing terminology

Category:IT risk management