What it is?
In a previous job I had it was the “Beer Truck” factor (you can see where our heads were) but the common term these days is Bus Factor. Put simply, it’s your projects exposure to the risk of key members disappearing tomorrow. To be crude if your project can’t survive a key member of your project being hit by a bus tomorrow then you have a very high “Bus Factor”.
[Side Note: At ZendCon 2009, Microsoft’s Josh Holmes rented a party bus to take people from the conference in San Jose up to the Bing Launch party in San Francisco. There were so many of ZendCon’s speakers on the bus that it was joked that the conference could not continue the next day if the bus crashed. The conference literally had a very high bus factor. Thankfully, they all made it back safe and sound, if a little worse for wear. :)]
Isn’t this just an Open Source problem?
How high is your project’s bus factor? Are there portions of the project that are only understood by a single person or small group? If so, it’s high. It’s not only open source projects that have bus factors though, I would propose to you that corporate projects and teams usually have a much higher bus factor than open source projects. In OS, you can grab the code, read it, learn from it, understand it and contribute to it as you like. Corporate teams are not usually setup that loosely. A developer may be assigned a part of a project and become the expert on that part. If he/she is the only developer who understand that part of the project then you have just increased your team’s bus factor.
If you are one of those developers that has worked themselves into a very secure position by writing code so arcane and interwoven that you are the only person who could ever understand it, you are a serious risk to your project. Beware, if your team reads this and understands what you’ve done, your position might unravel quickly and you may find yourself looking for a new team to put at risk.
How can you avoid it?
OS projects can easily reduce their bus factor by simply encouraging people to distribute their work around the project. Don’t let developers get pigeonholed in a specific component or feature, encourage them to work in different areas thus learning more of the system. Also, routinely check your procedures to make sure you don’t have a bottleneck. If there is only one person who can do any given task, cross-train someone else to do it. Make sure every critical account has more than one ssh key attached to it.
Corporate IT teams are going to have a harder time reducing their bus factor but it can be done. First, team leads should actively look for developers who have been working on a single part of the codebase for a long time. (You get to define what “long time” means in your team.) Ferret out those developers and move them to other projects. Move someone else into that slot but don’t let them get comfortable there either. Also, cross-train like mad. Spend one lunch break every two weeks letting a developer explain the part of the code they work on while the rest of the team listens and eats their lunch. There should not be a part of the system that is treated like a “black box”. Try to achieve the goal of every developer at least understand all the moving parts of the system, even if they aren’t actively maintaining them.
Your project’s bus factor can be reduced unless you are the only developer on the project. It’s simply a matter of spreading knowledge around. Encourage curiosity in your team members. Give them time on the job to explore the system; stop sweating whenever you hear a truck roll by.