Boost your project's bus factor

A person was crossing the street when they were hit by a bus. He or she was unconscious and was taken to the hospital. If this person is a member of your team, is there a member who can fill in without any gap in knowledge? In a disaster project, no one will be competent enough to fill in.

What exactly is the bus factor?

The Bus Factor is the number of people on a software project that have to get hit by a bus for the project to stall. It is not, however, limited to being hit by a bus, but also includes scenarios in which team member(s) marry, go on vacation, change jobs, or are otherwise unavailable.

John and two companions set off on a long-distance road journey to the east. His pals can drive, but only John is familiar with the road.

If John suddenly became unable to continue, his pals would be unable to reach their target. In this situation, the bare minimum of persons who must be unavailable is one. As a result, their bus factor is one.

The lower the number, the higher the risk, except when the number is zero.

In a product team, developers or project managers create territory over files or features in a project. The effect? Nobody else knows what’s going on in it. How many times have you heard someone say, "Joey worked on that; I'll tell him to do it."? It is a common behaviour. For your project to run smoothly, it is imperative we "boost your project's bus factor" (Leonardo DiCaprio points).

How to Boost Your Bus Factor

If you’re working on a project alone, the only way to increase your bus factor is to increase the number of people involved. Open source and adding contributors are ways to protect the project's continuity. Afterwards, when the number of contributors increases to a significant number, you should practice the following.

Encourage code review.

The number of people active in a code review is directly proportional to the project bus factor. Team members should be encouraged to take part in code reviews. It helps them understand how fellow team members think and execute ideas. This ensures that implementation knowledge is shared across the team. Code review increases code quality and readability, which will make it easier for new members to work with.

Write documentation

Team members should be encouraged to write documentation. The presence of good documentation makes it easier for them to understand what was done. Good documentation is not only good for critical situations and knowledge sharing, but also helps the writer think and spot design mistakes. Examples of documentation include testing, design documents, general documentation, and code comments (where necessary). ‘ Love documentation.

Redundancy

Redundancy is the duplication of a critical component or function of a system to increase the reliability of the system. The concept can be applied to a team by making a clone of key team members and storing them in a freezer. Just kidding! Or am I? Shared ownership enables redundancy in the software team. The goal is to make contributors believe they own a feature, when in reality, no one does. This not only helps avoid territories but also improves cohesion among the team. For example, bug fixes are usually assigned to the author of the relevant part of the code to ensure that the fix is completed quickly. Instead, the fix should be assigned to someone who isn't the core author in order to help them become more familiar with the section.

Pair programming should be encouraged.

Pair programming is when two people write together on one machine. This process improves communication and cohesion. Although it can be counterproductive if not implemented carefully, it can be implemented in scenarios where a core feature is being developed or an important fix is needed. When it is properly practiced, implementation knowledge is shared among members. It also helps developers of different experiences learn from one another.

Encourage high-quality code.

When code quality is poor, experienced team members will shy away from tasks associated with that section. No one wants to be blamed for something they didn’t create (I had a dark joke for this section but later deemed it unnecessary). Quality code should be of the utmost importance to your developers. When a project has quality code and team members are willing to work on any section, the bus factor increases.

Dispensable team members

Great developers make themselves dispensable by carrying the team along and sharing resources with the team so everyone can grow and learn. A software team achieves greater heights when members challenge one another and want one another to succeed. The team will work effectively without you. At that moment, you know you can sleep better at night.

A friend recently told me how his company was in jeopardy when a senior backend engineer who is effective and works across multiple codebases decided to leave. It cost his company time and money to have other developers take over the projects. Following that, they adopted a new guideline stating that each individual should only work on one project at a time. That, too, isn’t a foolproof method. The technique only mitigates the impact of the low bus factor across projects; however, each project remains vulnerable.

We all want to see our project thrive, and a low bus factor puts us at risk. Fortunately, we know how to effectively reduce this risk. A high bus factor is good for our project continuity, and there is no reason why we should not increase it. You should have a meeting with your team to educate them about the risks. It is never too late to make changes. It's better to be late than never. Good luck, and Godspeed!

Please give me claps and follow my account Locksi, if you enjoyed this article. I write about my experiences as a software developer and various topics related to technology.