Bus Factor

How not to lose your business by 'hit by bus' factor


The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase β€œin case they get hit by a bus”.

One sentence explanation: calculate your bus factor risk, if work could not continue with the absence of just one specific key person, you have a bus factor of 1, a higher bus factor helps businesses continue working without any critical dependencies, so try to keep your bus factor as high as possible.

But how can I improve my bus factor running one of my businesses? Let’s discuss some useful points right now!

All of the hints below are mandatory for a person who is leading a project or taking a key role in the development. Besides, I would recommend following those practices no matter if you care about the bus factor or not since it will help you to keep a qualified knowledge sharing, high code standards, and well-written documentation throughout the projects.

Reassign 🀝

I bet you have an all-star developer in your team, which always gets most of the assignments. Your company/team has to be prepared for him to leave or be absent. Re-assign him to a different part of your project or to a completely different task. His replacement will have time to complete a knowledge transfer and ask questions.

Code Reviews πŸ‘€

Code Reviews help to find bugs, get familiar with the project structure, code conventions, and team review practices. It’s a common practice to set at least 2 pull request approvals before merging it. Make code reviews a mandatory ceremony among the developers.

Pair Programming πŸ‘¨πŸ½β€πŸ’»πŸ‘¨πŸ½β€πŸ’»

Working together is the best opportunity to share ideas and to improve yourself. Pair Programming is always about friendly cooperation (it should!). Junior programmers learn much faster by pairing with experienced team members. Also, you can quickly identify a bad hire.

Tests Coverage πŸ“ˆ

Functional tests help developers to understand the project very quickly. Well-written and properly described tests can easily help to understand the piece of tested code.

Regular Meetings πŸ—£οΈ

Daily standups are a must. If your team does not do daily standups, ensure to meet all the team members to gather and share information about their progress.

Documentation πŸ“„

Try to keep your documentation consistent. Always document specific pitfalls and bottlenecks. Always spend some of your time reviewing the actual state of your documentation.

Automate Things πŸ€–

Some complex or routine things can be optimized and automated (for example Continuous Integration with Continuous Delivery instead of manual build processes).

⚠️ The bus factor may be hidden (it does not have to be about the project or its codebase knowledge. It can be just a password that is not shared or an account that is the only one with specific rights)