Truck Factor Measurement

How many developers can your team loose

before your project is in serious trouble?

This is the central questions that the so called Truck Factor (a.k.a. Bus Factor) tries to answer. The concept originates from the agile community and can be initially thought of as a metaphor, just like Technical Debt. As researchers, we are always extremely thankful for theories developed by practitioners, as they provide often times a more solid and practically relevant foundation for further research investigation than theories coming from the research community.

Computing the Truck Factor implies gaining insight into how knowledge is spread across a development team, and how this knowledge overlaps. In best case, the knowledge about code, design, test cases, and other software artifacts is spread evenly across the team with great overlap. For example, at least two developers should have knowledge about a single artifact to guarantee a truck factor greater than one. In worst case, exactly one developer knows each artifact exclusively (e.g. the creator of the document). As example, one developer might be the "owner" of the GUI front-end code, whereas another developer is exclusively responsible for the database back-end coding. These situations are typical examples for high-risk situations (and low truck factor) since the loss of a developers leads to significant loss of knowledge.

To approximate the Truck Factor by the use of existing data, a combinatorial analysis on a project's version control system can be conducted. The key idea is the usage of information on file ownership stored in the version control database. Typically, software components, and other artifacts (test cases, plans, documentation, UI designs) are created and modified by the users that know the artifact best. For example, a source code file might be created by developer A and modified by developer B, but never maintained by the remaining team members. This information leads to support the belief that both developers share knowledge about the source code, and that the other developer can compensate the loss of one of them. We describe the approach for approximating the Truck Factor in our 2010 paper:

Using this techniques one can plot the Truck Factor Chart which shows the worst case scenarios for loosing team personnel:

The chart above shows the impact of loosing team members on remaining code knowledge. The light-blue HeRa project is a typical instance of a one-developer project. Loosing the lead developer (ak.a. hero) will lead to a loss of 65% of code knowledge (which are the code files that no other developer has worked on). The red and blue XP projects (Zeit and KlaRa) show better characteristics. Both project teams used pair-programming and pair-switching to control for better distribution of knowledge across the team. Both projects can loose 1-3 team members with only loosing up to 20% of code knowledge.   

Tool support for computing the Truck Factor Chart has been implemented into CodeVizard, a tool for mining and visualizing code repository information.

If you are interested in participating in a Truck Factor study, I will be happy to collaborate with you and your team. Please use the information provided on my contact page.