Can other people continue working on your projects if you are hit by a bus tomorrow? How long would it take them to start making changes that actually mean something? Could they even get started? In other words, what's your project's Bus Factor?
The Bus Factor is the number of programmers that need to be incapacitated before a software project can no longer continue. "Incapacitated" doesn't have to mean actually getting hit by a bus; it could mean that people are taking vacations at the same time, or are out sick at the same time, or even how many people can quit before a project is in serious trouble.
We should be very conscious of this number, because in my experience, the Bus Factor is often 1.
Think about your projects. Are they complex? Did they take months or years of research and learning to implement? Are they used by other persons, and how often are they changed? Who are the users, and what do they want? You'll probably know the answers to most or all of those questions.
Will your coworkers?
A low Bus Factor is a very real indication that your project is in danger. If your lead programmer gets very ill and can't come to work, will you have to pick up his projects? Do you even know what they are or what they are used for? Can you easily step into his shoes, and he into yours? If not, your project may be in trouble. So what can we do to improve this number?
First and most importantly, we can share responsibility. On any given project you'll likely have a lead programmer, or at least some person who is in charge of getting that project done. It is the responsibility of that person to make sure there are enough other people on that project that if one of them is incapacitated, everyone else can pick up the slack themselves or can help train another person on how to maintain the project. The leader can make it her mission to avoid programmers who lock themselves in ivory towers.
There's something else we can do to mitigate the Bus Factor as well. If one of the programmers on a given project is incapacitated, how can another person of similar skill quickly pick up the project? By having that project adhere to the team's code standards.
Standards save time! Specifically other people's time, for if all the code is structured in the same way we don't have to spend time learning a new structure (or naming convention, etc) each time we start working on a new project. Following your code standards (whatever they are) is a superb way to mitigate time lost in the event of a catastrophe.
The Bus Factor is a quick way of knowing how badly your project would be stalled if one of the programmers on it was removed from it without warning. How do you improve your Bus Factor?
