BUS factor or "one is a bad number for business"

For those who are not familiar with the concept of bus factor, let's refer to the first thesis from wiki, which says that the BUS factor is a factor that shows the number of participants in the project, after losing them (in the original - "hit" by the bus), the project can not be completed by the remaining participants.

You may have also seen the term truck factor or brick factor, but the essence does not change.
If try to translate from IT language to human language, the bus factor - is about "what will happen to your business/project, if you lose this particular member or team, in whose hands or minds there is 90-100% of information for the project to work?

By answering this question, we can see areas of project vulnerability and make straws where the valuable information that drives our project is concentrated in the hands of one individual.

The worst number for a business is one:
- one sales channel (can fall off or become ineffective overnight and have to spend a lot of time setting up additional sources of getting traffic;;
- one client, even if it's a big one (if it leaves, the team will be broke);
- one person who knows how all the business processes are set up;
- one developer who has all the accesses, and they do not belong to you, and your business literally depends on him to be online;
- one developer, who developed your software, but left no technical documentation, and no one but him knows how everything is implemented and will spend days, weeks, or months to understand the logic of what's going on.
You can go on and on forever.

The point is this: if your business or project has one or more vulnerability zones, where the resource is concentrated in the hands of one specialist, you have a high level of bass factor.
The bass factor can be any event, from "got hit by a bus," to "suddenly got sick" and didn't get in touch when you critically needed it.
An easy way to digitize your bus factor is to take the number of people involved in a project.
Since we're writing this article on a web development studio blog, let's take a scenario from that area.

Let's say you have 7 people involved in the project, of them 1 project manager, 1 business analyst, 3 developers are working on the backend and writing code, you also have 1 front-end and 1 designer.
In the context of software development in this project, the bass factor equals 3, because the key information is dispersed among the 3 developers of the backend.
If you have a small company, and you work with freelancers or individual developers, your bass factor is also equal to one.
And this is where it should get more exciting :)

5 basic steps how you can reduce the risks of a high-bus factor project, if you are a customer:

1) Insist on registering the domain to you, not the developer/marketer;
2) Insist on registration of the hosting in your name, not the developer's, and give access to anyone who needs it from your account;
3) Insist on a server registration for you, not for the developer, and similarly give access to other project participants, rather than depending on someone from the outside;
4) Agree to work to the TOR (terms of reference) so that anyone else can figure out what you were doing "before" you brought someone else into the project;
5) Ask for the preparation of technical documentation, especially for complex architectural projects, which will have a nested structure of links and a large number of modifications of the functionality in the future.

It is worth noting that the work with the TOR and the technical documentation is more time-consuming for the specialist or team, in the context of man-hours workload, and therefore will cost a little more for you as a customer. However, this is the case when showing the proper level of respect and attention today - you will save more time and money to the company tomorrow, the day after tomorrow and years later.

7+1 basic steps on how you can reduce the risks of a project if you are the development team or an individual specialist:

Point №0. There should be a repository for every single project you need, with a description of how to deploy the project.
1) Create a knowledge base and technical documentation for the project, and store it in the company cloud, not in individual developers' personal clouds, and certainly not in local files on individual developers' laptops or computers;
2) The repository must be accessible by more than one developer with full credentials;
3) Make regular backups of important data, preferably not on the same server as the production.
4) Systematize requirements for code documentation, naming of classes and variables, location of modules in the project, and so on. The more things you standardize, the less the bass factor will be on a project with any number of developers.
5) Do code reviews of all developers, even those who write "like God" (especially if they write "in their style").
6) If there are any commented out chunks of code in the project, always indicate why they are commented out and when they cannot be touched or uncommented.
7) If some part of the work (let's say CI/CD) was configured by one specialist, and no one went into details of how he configured it - ask him to draw up a technical documentation, so that you don't have to go to him every time you need to change it.

To summarize, I want to add that bus factor is absolutely in all projects and businesses. The only question is how high or low it is.
As a rule, small companies and teams are characterized by a more critical level of bus factor due to the concentration of a large amount of information in the hands of individuals. As the business grows and the number of people involved in the implementation of tasks grows, the bass factor becomes lower.
However, from time to time any project needs to be "revisited" for vulnerabilities in the context of the bus factor.