Search for a command to run...
A short explanation of the Bus Factor and how to hold its score at safe levels
I'm a software developer with almost 20 years of experience, eager to share knowledge earned during my journey in programming. Lastly worked as Engineering Manager at Aterian, and previously as Staff Software Engineer at TUI Musement, CTO, tech/team leader, and software architect. I'm also an active open-source contributor & maintainer.
I must add to this: choose a right technology stack!
Sticking to most popular choices in your technology stack increases your project chances to find more people familiar with this stack.
It helps recruit new people, makes easier to onboard new members and overall maximizes bus factor.
So for any kind of project, built from scratch or legacy: select well-known technologies, or switch to them.
In this series, I will write about topics around team management. From problems to possible solutions for those.
Hold my beer, I can do it on my own! NIH (Not Invented Here) syndrome is often considered an opportunity to prove to ourselves that we can do the same thing, but better, faster, nicer, and more secure than the original. According to Wikipedia, we can...
Learn how to write a custom PHPStan rule to prevent “code smell”
Hold my beer, I can do it on my own! NIH (Not Invented Here) syndrome is often considered an opportunity to prove to ourselves that we can do the same thing, but better, faster, nicer, and more secure than the original. According to Wikipedia, we can...
Recently I have read a book: The Phoenix Project by Kevin Behr, Gene Kim and George Spafford; About what the book is? It's a business novel, where fiction is used to point the reader to some of the business values, but unfortunately in my opinion it...
While the title may sound quite extreme, a similar sentence was asked publicly by Michael McLay in 1994:
If Guido was hit by a bus? (Guido van Rossum is the creator of the Python language)
That question led to the creation of the Bus Factor, known also as bus problem, truck factor, lorry factor, or even lottery factor.
While there are several slightly different definitions on the Web, we may summarize them as:
The Bus Factor is the total number of people who would need to be incapacitated, as by getting hit by a bus so that the project would be left for dead.
To make this more descriptive, the Bus Factor score is an estimation of people who are so vital to your project that without them it will stall. If those people disappeared from the project for any reason (like an "accident" or even taking holiday, got fired, or left the project), no one would be able to maintain the project.
The lowest possible Bus Factor score is just 1, which means that if one person leaves the project it will stall or die. From a more technical point of view, this could be considered a single point of failure within the project. A much larger Bus Factor score is preferable, but not always easy to achieve.
Author: https://xkcd.com/2347/
At end of 2021, the PHP community received the sad information that after 10 years of implementing innumerable bug fixes, features & maintaining PHP, one of the main contributors: Nikita Popov, decided to focus on working in a completely different language and community (Rust & LLVM), of which he had already been apart for a few years.
Similar to the history of the Python language, that decision showed the PHP language has a really big problem with such a low Bus Factor score. It put the future of the language that powers up ~78% of the Web in a dangerous position.
To improve the current state, people and companies working on PHP joined forces and started a new initiative: PHP Foundation.
The PHP Foundation is a non-profit organization whose mission is to ensure the long life and prosperity of the PHP language.
The first decision made by the foundation was to hire/sponsor new developers to work on PHP core components. That way they could start increasing the Bus Factor score to a safer level. This is one of many steps that need to be taken by the community to make PHP's future safe and stable.
Plenty of companies I worked for, from startups to corporations, often were hit hard by the Bus Factor. Many of their teams (most of the time not intentionally) fell into NIH (Not Invented Here), which led to problems with maintenance, higher entry-level for newcomers, as more & more things were created by people who could leave the project at any moment. This has often led to high Technical Debt (which I will try to explain in a later post).
A low Bus Factor score is often part of the fast-growing time when only a few developers create most of the functionality that later becomes the base for an increasingly complex project. Most companies start big hiring plans during such growth, but that's not something that can increase the Bus Factor alone.
Each new member should have at least 30 minutes of a pair programming session with one of the senior people within the project she/he is joining. During such sessions, a less experienced person should do most of the coding, while the senior mentors, leads by example and suggests parts that may help to achieve the goal of the task.
When you identify Bus Factor people, you should focus on how they can share the knowledge they aggregated during all those years in your project. Their knowledge is one of the biggest values for your team. Have them focus more on writing documentation, creating cheatsheets, doing internal presentations, and sharing knowledge in one-on-one sessions with teammates. Their focus on programming should be reduced.
While adoption of the Code Review Culture is done by teams to improve the code quality and the review process, the less obvious outcome is direct knowledge sharing between people in the project. Reviews must not be just like giving a stamp of approval. They should point out why something was done that way, not another, leading to constructive discussions between seniors & other teammates about what could be done differently, from the perspective of seniors. Reviews must lead to discussion.
Often the problem of fast-growing companies is fast-growing Technical Debt, which leads to a low Bus Factor score. One of the effective techniques is reducing the complexity of projects by splitting them into smaller, more dedicated ones. This leads to lower entry-level, faster adoption, and easier maintenance. All these points allow increasing the overall Bus Factor quite effectively. The biggest issue you must avoid during reducing the complexity of projects is to always involve teams (even small ones) in refactoring to avoid creating the very same problem in the new sub-project(s).
This can be the most effective way of increasing the Bus Factor score, but it's also the most difficult and dangerous one. You need to deeply plan every possibility to prevent losing team morale. "Shuffling" should not be forced, but proposed to team members on a regular basis, like: once every two quarters; teammates cannot change teams too often as they will need to be onboarded like a newcomer. If well planned & executed, your teams will get much wider experience in different domains, sharing the knowledge learned while working with other teams.
Planning training budgets for your developers can also increase the Bus Factor score as people will gather a wider range of experience, and expand your team to have more people in each seniority rank within your company hierarchy.
It’s not that easy, cheap, or quick to increase your team Bus Factor score. There are cases when you don't want (or even can't) easily increase that score, for example when the project contains sensitive data and you can't trust your new hires to start handling it. But now you know some of the basics that can help you prevent having your operations grind to a halt due to a "bus accident".