The bus factor: Why an 82-year-old developer can become a business risk

And why software projects need more than just good code

Bus factor? What does it mean? The bus factor, or truck factor, is the number of people who have to be run over by a bus before a company is unable to operate in certain areas.

What sounds macabre is a real threat to businesses: If the knowledge of certain projects, systems, processes or central authorisations is in the hands of just one person, the worst-case scenario is that the machinery grinds to a halt. This is why the development or adaptation of business-critical software includes a detailed analysis of responsibilities.

‍

Bus factor: definition

The term bus factor comes from risk management and assesses project risks. The aim is to indicate the maximum number of people who can be absent in order to incapacitate a company in a particular area; the lower the number, the higher the risk in the project. A bus factor of 1 is therefore the worst possible number. This is because it indicates that a single team member is critical to the success of a project, the control of a system or the delivery of business-critical software. If that one person fails, the organisation has a real problem. Production stops, delays, system failures, etc. are the result, and expensive replacement solutions are required.

“Could an 82-year-old developer pose a risk? ”

What sounds macabre or even very pessimistic is often the case, as Marcel Dambach, Team Lead Software Engineering at generic.de, knows. In his role, he spends a lot of time with customers, analysing responsibilities and project risks.

He says: "In principle, most customers are aware that individual knowledge holders responsible for competitive software, for example, represent a potential risk. They don't have to be hit by a bus. But even though the latter is a predictable risk, it is often overlooked or ignored in the day-to-day running of the business.

I've already experienced this on a project: we were reworking a very old piece of software that was critical to the business. When asked where the source code was, he said: "Yes, that's one of the reasons you're here. The only one who knows the software is our former colleague. He still does it on the side, although he is 82 years old and has been retired for 15 years". We almost fell off our chairs. "

‍

Risk analysis with RACI chart: Who am I and how many?

In this case, the risk was obvious and known. But that is not always the case. In order to show where there could be potential vulnerabilities, generic.de works with the responsibility assignment matrix, or even RACI chart.

A RACI diagram describes the responsibilities of team members in a specific project in four different categories:

• Responsible | Execute task: This person is responsible for completing a specific task within the agreed parameters and an agreed deadline. A task can have multiple responsible people.
• Accountable | Project Supervision: Accountable is the person who ensures that the task is completed by all responsible members. This responsibility should only be assigned to one responsible person who acts as a decision maker and supervisor throughout the project and ensures that the task is completed to an acceptable standard. In order not to generate a bus factor=1 yourself, a representation rule should be set up here directly.
• Consulted | Information provision: The “consulted” person is a knowledge carrier in the team. This person provides help, additional context, and advice about the task, provides all the information you need, and provides access.
• Informed | Receives status updates: This is a stakeholder who receives or needs information about the project. The “I” can be many people, such as a management team or the department manager, who must report the project upwards.

The RACI model for software projects addresses issues such as Who has what access? What are the authorisation levels and who has them? Once this matrix has been created, you can see at a glance who is on R too often, or where the rules of representation need to come from.

Marcel Dambach knows: "Sometimes people who have a lot of responsibility don't want to give it up. Then you have to persuade them, preferably from outside. The bus factor argument can sometimes be a wake-up call. "

‍

Actively promote knowledge sharing to ensure traceability

What applies to the RACI matrix applies throughout the project: There must be constant communication between all project participants. Without regular communication or documentation, the same problems can arise as at the beginning. The result: No one knows what was developed, why and how. This is a particular problem when it comes to the evolvability and traceability of code, which, according to Marcel Dambach, is a key factor for many customers when choosing a development partner:

"Customers no longer want to be tied to a particular product or company. Vendor Lock-In, which prevents customers from switching suppliers, must be avoided. We guarantee this by working in complete transparency with the customer, who has full access to the source code at all times. By applying the Clean Code Development Principles, we ensure that technical debt is minimised. This means that we and other developers who may take over the project at a later stage can understand why decisions have been made. "

‍

Conclusion: Check risks again and again and avoid them as a preventive measure

In summary, the bus factor should not only be checked when the person concerned is already in hospital. Rather, especially in the case of business-critical processes or software, it should be checked again and again whether the assigned roles are still coherent and whether the company remains capable of acting at all times. The same applies to software: here too, the RACI model should be used to ensure that there are no critical dependencies to avoid vendor lock-in.

‍