I decided that I would write this article one lunchtime, but by the time evening had come around, I had completely forgotten the topic of the article I had intended to write. Fortunately Richard had been at lunch with me and he could remind me that I was to write about Bus Factor -- I can't think of a single better example of why this is important to do.

Bus factor is, quite simply, the number of people who need to become "indisposed" before a project will falter. As the linked Wikipedia article says, it is a measure of the concentration of critical information in a project.

We encounter the issues of bus factor almost every day when we learn something unique in our day-to-day work. As information workers, the generation of unique knowledge is our bread-and-butter and we need ways to ensure that the knowledge we create is not lost if we are. We do this by way of writing things down, telling them to others, putting them in knowledge-management systems and any other thing we can do to ensure that the knowledge is safe.

As software engineers we do this a lot of the time by committing our new knowledge as source code to a revision control system and pushing it elsewhere. Of course, we then sometimes don't improve the bus-factor but instead create a single-point-of-failure for the hardware infrastructure we depend upon.

What's more, as knowledge workers, we have two conflicting desires at the root of our pursuit of knowledge. We like to know things that others do not know since that gives us a measure of smugness or superiority. We enjoy learning new things but above all that we enjoy inventing new things and holding those precious nuggets of joy to ourselves for a short while. Conflicting with this desire is the desire to be seen to be clever/wonderful/inventing new things. Fortunately that second desire is the one which reduces the bus factor for the new knowledge and it is to this second desire that we must adhere.

When software projects begin, typically they begin with one person having a clever idea. That project intrinsically begins with a bus factor of one. Hopefully, if the project gains users, the project will gain further developers and in doing so will reduce its bus factor providing the developers share knowledge and understanding rather than segmenting the project and never encroaching on one another's domain. Fortunately F/LOSS projects tend to be run in a way which encourages the sharing. So if you start a project, please make sure you write stuff down and do your best to get at least one other person involved, ideally before you have users depending on you.

After all, it could be you who goes under a bus tomorrow.