Mitigating the Bus-Factor

How much of your software code base is at risk if one of your developers leaves the project, gets sick, or joins another company?

In large team projects, although the entire project may not be at risk, how do we identify which modules / components are at risk? Usually, a team can exercise some gut-feel whether a component is more or less reliant on a single developer. Sometimes, management may even actively seek to mitigate this risk by getting another developer involved with the coding.

This leads to a question: How does management measure whether there is an improvement in the risk management, i.e. the second developer has started to have some ownership over the code-base?

In a commercial enterprise, this [ most project members make a relatively small number of commits, but an individual or small core group of individuals make a much larger set of commits. ] may be more of a concern (due to the time and cost implications of sudden replacement) than in open source projects, where by definition, the openess of the codebase and contribution process offers a buffer against adverse consequences of key man risk.

Source – Rory Winston, Research Kitchen Weblog

Rory goes on to propose the use of the Gini coefficient to measure how reliant a project is on a single contributor.

What I find interesting is that we can apply this metric to individual files, or components, or modules, and use it to guide us where developers should be deployed in the next project cycle. Furthermore, it allows risk management to be taken into account, as a deliverable KPI, and not only on the basis of efficiency and velocity of delivery. Having a developer work on an unfamiliar codebase is slow and is risky, while a developer who is upgrading code that he had written can be three to ten times faster than someone new. Of course, managers are tempted to go down the efficiency route.

It is said that you can’t improve what you can’t measure. Rory’s suggestion is one little step towards objectively measuring code-risk.

You should follow me on twitter here