In the software development business, there exists many risks that endanger not the only the success of a project, but even its survival. One of the roles of a good project manager is to take those risks into account, and be able to measure them. As one of my teachers in engineering school always stressed, a metric that can't be measured can't be controlled nor dealt with.
And one of the most important metrics in a software project is the Bus Factor.
What's the concept ?
When designing scalable and reliable software, one of the first questions we should ask ourselves is what is the single point of failure of the system ? And it is a very important one, since as you already know, it can easily cause a bottleneck and therefore stop the whole application.
Well the Bus Factor tries to ask the same question, but this time about the development team. The question of What is the minimum number of team members that should get hit by a bus before we loose a necessary knowledge about the project. (It's a very dark question to ask !)
Although having many members of your team getting hit by a bus is statistically very unlikely, however having some of them leave the team unexpectedly, either because of a new job, new lifestyle, new family situation, etc..., is highly probable. And it is precisely for this reason that this factor is very important.
How do we measure it ?
Let's take for example that a project is composed of three distinct entities: the Front End team composed of 5 people, the Back End team of 10 people, and the DevOps team of 3. Let's assume that every team member perfectly knows about what its team is working on only.
In that case we can see that if the three members of the DevOps team get suddenly hit by a bus, we loose the ability to work on the project. And therefore you can guess that the Bus Factor of this team is 3.
How do we deal with it ?
The reason we decide to measure the Bus Factor is to try to maximize it. The higher the Bus Factor is, the lower we are exposed to an unexpected loss of knowledge. Ideally we should aim for ideal number which is the number of our team members. On the contrary, a lower Bus Factor means a higher exposure, and the closer we are to 0, the worse we are.
You should always share knowledge between your team members to have the highest Bus Factor possible !
In the midst of excitement when working on a new Software project, we often forget some basic project management concepts. And best practices are here to make sure we don't forget some of them like the Bus Factor. This shows the importance of practices like Code Review or pair programming that take into account this kind of factor, and help prevent a low metric.
Top comments (0)