What if the solo developer in your team gets hit by a bus?
Form an imagination for a while. A guy named Swat is the only programmer in your dev team who codes multiplayer game architectures in an underway project. Once on a rainy day, he decided to get married, leave the project or maybe got hit by an actual bus on his way to work. Now the code written by Swat is an obscure pandora’s box. You can’t touch the multiplayer code. The code belongs to Swat. Oh, wait for a second, what happens now when Swat is gone? The project, your team, your input to the project and the whole process is in trouble. The bus effect.
Bus factor is an old jargon; a term used widely in the software and programming community. It is a factor to measure the effect of risks involved over the software development process in the form of an actual bus or similar analogies.
“Bus factor is the number of people on your software project that have to get hit by a bus that are going to leave you in a world of hell. So, if there’s only one person that knows that really obscure file-system code and they get hit by a bus, whether that bus comes in the form of an actual bus, or they get married, or they have a kid, or they change jobs, or they move away or they get bored…” – Brian Fitzpatrick, Google
The bus factor should be high in a collaborative team working on a software project. The higher the number of people being familiar with the code the lesser the risks of the code being unknown to the others in the team.
It’s a common problem in a small project with limited manpower and resources. We neglect the foreseeable outcomes and work ahead in anticipation of good sunny days. So one of the important things to look out for in a collaborative software team is to watch out for your only, solo and lone-wolf programmers in the team. As a team lead, you should work on reducing the number of lone-wolf programmers in your team who are working in an unknown or obscure codebase for a longer time. Try having many team members get familiar with the code.
In a programming community, SPOF (Single Point of Failure) is a critical term. It refers to what it abbreviates to in full; a single point that would cause a failure that would cease the whole system. In regards to the Bus Factor that we’ve been talking about, SPOF correlates with the Bus Factor in similar ways at some points in a software development process. In other ways, many software teams also translate Bus Factor to understand as someone who is very very important to the project. Hence a single point of failure to the team and to the project.
Things that can reduce the effect of SPOF in your software team:
- Plan early for the risks in your project
- Get multiple SME (subject matter experts) involved early on in your project - team members with deep understanding of a specific domain.
- Avoid, Minimize, Transfer and Accept - Use these 4 basic risk mitigation strategies to manage single point of failure risks.