Bus factor

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

In software development, the bus factor is the number of key developers who would need to be incapacitated to make a project unable to proceed. It is also known as truck factor,[1] or bus/truck number or lottery 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, 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 1994,[3] itself an evolution of the work published in the first book of the PLoPD series in 1995,[4] which was the publication record of the first PLoP conference in on 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 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 what would happen to the Python language if Guido van Rossum were hit by a bus.[9]

References[edit]

  1. ^ http://www.agileadvice.com/2005/05/15/agilemanagement/truck-factor/
  2. ^ 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?"
  3. ^ Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley. 
  4. ^ Coplien, James; Schmidt, Douglas (1995-05-12). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley. 
  5. ^ Coplien, James (1994-08-04), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished. 
  6. ^ Simon, Robert (17 May 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". 
  8. ^ Reinholdtsen, Petter (2005-11-11). "Re: Resignation and uploads". https://lists.debian.org/debian-devel/2005/11/msg00801.html.
  9. ^ McLay, Michael (1994-06-29). "If Guido was hit by a bus?". http://legacy.python.org/search/hypermail/python-1994q2/1040.html.

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