In software development, many risks can jeopardize the success of a project, or even threaten its survival. One of the main responsibilities of a good project manager is to take those risks into account, and measure them. As one of my teachers always stressed, "a metric that can't be measured, can't be controlled".

One of the most important metrics in a software project is the Bus Factor, even though it is not much spoken about.

What's the concept ?

When defining the metrics of software reliability, one of the first questions we should ask ourselves is: what are the points of failure of the system ? And it is a very important one, since it easily creates bottlenecks.

Therefore, the Bus Factor tries to ask the same question, but this time about the development team: What is the minimal number of team members that we can not afford to loose to a bus accident ? (Indeed, it is a dark question to think about !).

Although having multiple members of your team getting hit by a bus is statistically very unlikely, on the other hand having some of them leave unexpectedly, either because of a resignation, a lifestyle change, a family situation evolution, etc..., is highly probable. We are all familiar with the turnover figures in the software industry. And it is precisely for these reasons that this factor is very important.

Diving in maths ?

Let's take a simple example to understand the metric's calculation.

Let's assume a project has a DevOps team made up of 3 members. Let's assume that every team member perfectly knows everything there is to know about the team's perimeter (a transversal DevOps team for example).

In that case we can see that if the 3 members of the DevOps team get suddenly hit by a bus, we loose the ability to work on the project while we can get by with one DevOps (although he will have to dramatically increase his energy drinks consumption). And therefore you can guess that the bus_factor = 3. Meaning we can afford to loose 2 DevOps engineers before the DevOps team stalls.

For a more realistic example: Let's assume now the project having a Front End team of 5 people. While 4 of them share the same knowledge about the application, the 5th person masters one critical side of the code. Therefore, it might seem that the bus_factor = 5, but in reality the global factor of the Front End team is limited to 1.

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, eventually leading to a sharp increase in development and maintenance costs. Ideally we should aim for the ideal number which equals the number of our team members. On the contrary, a lower Bus Factor means a higher exposure. And the closer we are to 0, more red bells will ring.

Knowledge should always be shared among team members to increase the Bus Factor as much as possible !

In the midst of excitement when working on new software projects, or just complex features, we often forget some basic project management concepts. And best practices are here to make sure we stick to them. The bus factor is among them, emphasizing the importance of practices like Code Review and pair programming, that take it into account implicitly.