Bus factor: Difference between revisions

Revision as of 06:28, 4 December 2015

Revision as of 17:14, 5 January 2016

Line 1:

[[File:A bus waiting at a pedestrian crossing in Lima.jpg|thumbnail|Will the project fail if this member is hit by the bus?]]

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 '''truck factor''',<ref>{{cite web|url=http://www.agileadvice.com/2005/05/15/agilemanagement/truck-factor/|title=Truck Factor|date= May 15, 2005|last=Bowler|first=Michael|publisher=Agile Advice}}</ref> or, '''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.

==Definition==

A project's '''bus factor''' is the number of persons it would need to lose in order for the project to lose its [[institutional memory]] and halt its progress. The bus factor is a measurement of the concentration of information in individual team members.

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.<ref>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?"</ref>

"Getting hit by a bus" could take many different forms where the project would retain information (such as [[source code]] or other systems) with which no remaining team member is familiar, including anything that suddenly and substantially prevented the individual from working on the project. This could be a person taking a new job, having a baby, changing their lifestyle or life status: the effect would be the same.

===Alternate definition===

A rare alternative defines the bus factor as the number of persons who are indispensable for the project.<ref>{{cite book|last=Coplien|first=James|last2=Harrison|first2=Neil|title=Organizational patterns of agile software development|date=2004-07-26|publisher=Wiley}}</ref> 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, and zero is considered the ideal bus factor.

==History==

Line 24 ⟶ 14:

A July 2015 study calculated the bus factor of 133 popular [[GitHub]] projects. The results have shown that most of them have a small bus factor (46% have bus factor=1 and 28% have bus factor=2) and the value is greater than or equal to 10 for just seven systems. <ref>{{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/}}</ref>

==Implications in Business==

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.<ref>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?"</ref>

"GettingTeam members do not necessarily have to get "hit by a bus" could take many different forms wherefor the project"bus wouldfactor" retainto informationapply (such- asany [[sourcenumber code]]of orevents othercould systems)occur within which no remaininga team member iscould familiar, including anything thatbe suddenly and substantially prevented the individual from working on the project. This could beinclude a person taking a new job, having a baby, or changing their lifestyle or life status: the effect would be the same.

A rare alternative definition for the bus factor defines the bus factor as the number of persons who are indispensable for the project.<ref>{{cite book|last=Coplien|first=James|last2=Harrison|first2=Neil|title=Organizational patterns of agile software development|date=2004-07-26|publisher=Wiley}}</ref> 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==