A "truck number" (also known as a "bus number" or "lorry number" depending on one's cultural background) is an informal metric for estimating the long-term viability of a software project. It refers to the number of developers who must be unexpectedly crushed to death under the wheels of an oncoming truck (or bus, or lorry) in order for the development team to lose some skill or piece of information that is critical to the successful implementation and maintenance of the project.
By definition, the truck number of any software project is an integer (a maiming, nervous breakdown, or untimely letter of resignation has just as much effect on the project's truck number as an actual fatality). For all practical purposes, this integer lies in the range [1,n] where n is the total number of team members. Although it might initially seem counter-intuitive, the truck number of a project is not really a function of the number of team members, but is influenced more by the team's organizational structure and development methodology.
If one wades through the plethora of resources and consulting services that optimistically promise to increase the productivity of a software development organization, one finds that there is no consensus as to whether a higher truck number or a lower truck number is better for any given project. This disagreement regarding the optimal truck number is attributable to two syntactically similar yet conceptually conflicting definitions that are circulating throughout the industry. A truck number is either:
- "the size of the minimum set of team members such that if all of them are run over by a truck, the project will fail." Using this definition, a higher truck number is desirable, as it is less likely that multiple important team members will suffer fatal accidents or be otherwise removed from the project.
- "the size of the maximum set of team members such that if one of them is run over by a truck, the project will fail." Under this second definition, the truck number should be as small as possible, since the loss of any one member of the truck number set dooms the project to failure.
Regardless of the definition one prefers, the essential goal is the same: try to minimize the number of people who are individually critical to the project's success.
It has been suggested that the concept of open source software allows a project to attain the mythical truck number of ∞ (under the first definition) or 0 (under the second definition), meaning that there is no individual person or small group of people on whom the software's success depends. This may indeed be true, or at least very nearly true, for well-established open source projects with a large, thriving community of developers. For example, if Linus Torvalds were creamed by a large motor vehicle tomorrow, it is extremely unlikely that Linux would wither and die. However, less established open source projects are still subject to the rules of truck number theory.
Some argue that the truck number is skewed because the truck decides which team members it will mow down, and it always chooses to run over the important developers. Proponents of this idea advocate a "project-chooses" model over a "truck-chooses" model, which entails rewording the definition of the truck number as follows: "the maximum set of developers such that if all of them are run over by a truck, the project will still survive." Under this definition, a higher truck number is more desirable than a lower truck number, with 0 indicating a project that has already failed.
Others have adopted a more complicated approach that is best described as a "fate-chooses" model. As every geek knows, fate is easily quantifiable via probability calculus, and thus the "fate-chooses" model involves calculating an adjusted truck number based on the statistical likelihood that any members of the team will be run over by a truck, and if so, the probability that one or more of the fallen were members of the truck number set.
The phrase "truck number" was first introduced by Jim Coplien, an author and retired researcher in the Software Production Research Department at Bell Laboratories. Interestingly, Coplien himself seems at times to confuse the two most commonly accepted definitions of his truck number, although in recent years he has consistently preferred the second definition, in which a lower truck number is more desirable. Initially, the phrase was enthusiastically adopted by adherents of the XP methodology, with the assumption that instituting practices such as pair programming and collective code ownership will yield an optimal truck number. Because the concept of a truck number encompasses all of the best aspects of bowtie humor and pseudo-mathematics, it is gradually gaining a wider following.
Sources:
- "More Fun With Truck Numbers." http://c2.com/cgi/wiki?MoreFunWithTruckNumbers
- Stephens, Matt. "Collective Ownership, Oral Documentation, and Scalability: The Perfect Storm." http://www.softwarereality.com/lifecycle/xp/storm.jsp
- "Truck Number." http://c2.com/cgi/wiki?TruckNumber
- "Truck Number Composite." http://c2.com/cgi/wiki?TruckNumberComposite
- "XP Practices: Collective Code Ownership." http://www.adaptionsoft.com/xp_practices_shared_code.html
- Williams, Laurie and Kessler, Robert. "Overcoming Management Resistance to Pair Programming." http://www.informit.com/articles/article.asp?p=29410