Lessons learned about Bus Factor (1/5): Introduction

This series of articles is taken from a talk I gave at the Berlin PHP Meetup.

Let me share with you a little story of mine.

About 2 years ago, I was working on a quite complex project to create a marketplace from scratch. We were two on the job, and my colleague was a much more experienced developer than I was. We finally made this app and released it. A few months after that, we had a bug in production concerning catalog importation, involving a complex system working with RabbitMQ and Elasticsearch. I had never touched that part of code. And my colleague was on holidays. I was designated to fix it. Cause you know… “you worked on this project, right?”. Sure.

The reality is that I didn’t know at the time how all this worked and I found myself completely lost and panicked to understand all this stack. In the end, I didn’t manage to fix that bug. It led to frustration, stress and loss of confidence from myself, my colleagues and my client. That was a horrible experience.

Sounds familiar to you? If so, this series of articles is for you.

Bus Factor?

Bus accident on Empire Way, 1933 by Seattle Municipal Archives (license CC BY)

You can find several slightly different definitions of the Bus Factor on the web. Let’s make a patchwork.

The bus factor is the total number of developers who would need to be incapacitated, as by getting hit by a bus, so that the project would be left for dead.

In other words, the bus factor estimates the number of developers that are vital to a project, for any reason (lack of understanding of their implementation or information withholding). If those developers are gone (on holidays, fired, or just away), no one is able to maintain the project or to add new features anymore. In technical terms, that could be considered as detecting the single point of failure within the team.

This little thought experiment can help you to detect this kind of situation before it happens. If you have a bus factor of 1 (which means that with just one developer away, your team does not feel like it can maintain the project), then you have a serious problem. The goal is to increase this bus factor to the maximum and share knowledge so that you can prevent your project from falling apart.

In this series of articles, I will try to give you a few lessons I learned about knowledge sharing within your coding team, and also outside your coding team. Because you would like all your colleagues (even the ones working on different projects) to be able to help you at one point. Or just because it also applies for when your client decides to put their own developers on the project. You don’t want them to be stuck and to contact you every two weeks. Even if they don’t contact you, you don’t want other developers to feel the same way as I did (because you’re a good person. I know it). In the very next article I will present the essential ways of sharing knowledge inside your team. This will be followed by two other articles about strategies that apply for every developer outside your team, and finally by a bonus article about detecting as soon as possible a Bus Factor issue.

Next is available here.