Bus factor
In software development, a project's bus factor is the number of developers it would need to lose to destroy its institutional memory and halt its progress. It is also known as truck factor,[1] or bus/truck number or lorry factor and is a measurement of the concentration of information in individual team members. A high bus factor means that many individuals know enough to carry on and the project could still succeed even in very adverse events.[2]
"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 with, 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.
"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[how?] 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 July 2015 study calculated the bus factor of 133 popular GitHub applications. 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. [10]
References
- ^ Bowler, Michael (May 15, 2005). "Truck Factor". Agile Advice.
- ^ 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?"
- ^ Coplien, James; Harrison, Neil (July 26, 2004). Organizational patterns of agile software development. Wiley.
- ^ Coplien, James; Schmidt, Douglas (May 12, 1995). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley.
- ^ Coplien, James (August 4, 1994), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished.
- ^ 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.
- ^ Redmond, Matthew C.; Newton, Paul (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF).
- ^ Reinholdtsen, Petter (November 11, 2005). "Re: Resignation and uploads" (Mailing list).
- ^ McLay, Michael (June 29, 1994). "If Guido was hit by a bus?" (Mailing list).
- ^ Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (July 14, 2015). "What is the Truck Factor of popular GitHub applications? A first assessment". PeerJ Preprints.
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.
{{cite book}}: 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.
External links
- Poisonous People, a talk that includes (among other topics) discussion of bus factor and how to increase it