Have you ever worked on a on a project that made you worry, "what would happen if the key developer or other key team members suddenly left or, even worse, got on a bus together and rode off into the sunset permanently?" This article gives some resources to help recognize and improve your project's bus factor.
|OpenSSF Best Practices - bus factor
5 Whys - "Why your 'best’ developer is your biggest problem"
5 Whys - "Two techniques to avoid the bus factor"
DeveloperExperience.io - "Bus Factor"
Have you ever worked on a on a project that caused you to worry what would happen if the key developer suddenly left or (even worse) was hit by a bus? Or, maybe you are the key developer, and you want your project to continue if something in your life forced you to leave. A project's bus factor is the minimum number of key people who, if suddenly left, would cause the project to end. Higher bus factors are better. Increasing the bus factor aids the sustainability of a project. Other terms synonymous with bus factor include "truck factor", "lorry factor", and "lottery factor". Each of these terms suggests the unexpected loss of key team members. Planning for sudden loss of key team members is important. Teams may ignore this part of planning, but doing so is like the provider of a family ignoring life insurance. It is an important part of continuous planning for project sustainability through all phases of a software project.
OpenSSF Best Practices are a wealth of information and up-to-date links for open source projects and are helpful for all software projects. The best practice criteria for bus factor is that it must be at least two. The bus factor section includes suggestions such as defining and publicly documenting key roles with the associated responsibilities and tasks, as well as a link to a truck factor tool for estimating the truck (or bus) factor of github sites.
5 Whys, a blog for software team leaders, has several short articles that can help to increase your project's bus factor, including the following two:
"Why your 'best’ developer is your biggest problem" has great suggestions for thinking through who the key team members are (including the project manager) and actions to increase the bus factor for your project.
- "Two techniques to avoid the bus factor" explains using push and pull techniques for sharing information among project members.
The DeveloperExperience.io "Bus Factor" article outlines good practices for increasing bus factor for software development teams as well as some common pitfalls.
These are just a few of the many articles about bus factor that are available. They are presented here to help increase the bus factor of your scientific software project and mitigate the effects of sudden loss of key team members.