What is your project’s Bus Factor?

January 4, 2011

Uncategorized

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.

Conclusion

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.

About Cal Evans

Many moons ago, at the tender age of 14, Cal touched his first computer. (We're using the term "computer" loosely here, it was a TRS-80 Model 1) Since then his life has never been the same. He graduated from TRS-80s to Commodores and eventually to IBM PC's. For the past 10 years Cal has worked with PHP and MySQL on Linux OSX, and when necessary, Windows. He has built on a variety of projects ranging in size from simple web pages to multi-million dollar web applications. When not banging his head on his monitor, attempting a blood sacrifice to get a particular piece of code working, he enjoys building and managing development teams using his widely imitated but never patented management style of "management by wandering around". Cal is happily married to wife 1.31, the lovely and talented Kathy. Together they have 2 kids who were both bright enough not to pursue a career in IT. Cal blogs at http://blog.calevans.com and is the founder and host of Nomad PHP

View all posts by Cal Evans

2 Responses to “What is your project’s Bus Factor?”

  1. mazeroth Says:

    This is something we’ve discussed many times where I work but little has changed in the last few years. I’m in a corporate environment and the goal is usually to cut costs and do the most possible with the least amount of resources (not unlike most other companies). Instead of spending money to higher bodies for backups, money is spent in areas that will produce more revenues with the hope that no one will leave.

    In my division, we have 4 developers and each has multiple hats to wear. We have applications in PHP, Flash/Flex/Air, .NET, Java, ASP – some on Windows/IIS and some on Unix/Apache. Other than two devs working on Java, we rarely work together nor have a good grasp on what the others applications are like. And because we each have plenty to work on, there is no time to sit down and learn more about what the others do.

    We know things probably won’t change so we are considering other options that may be helpful if the day comes where one of the 4 devs leaves. The biggest one being consistency among all with architecture, folder structure, nomenclature, similar frameworks, etc. If we can all code in similar ways to one another, when the time comes, it should be easier to pick up where the other left off.

  2. caseydk Says:

    I’d wager that the Bus Factor in most companies is higher on average. Not only is the code limited to employees (and maybe contractors), but just getting to the point of being an employee is high.

    In Open Source, even if a project is "dead" or the team has fled, people who might be interested can find, explore, and even pick it up. In a company, once the team starts bleeding people, it may be too late. A random interested person isn’t going to accidentally find it because of the "gatekeepers" of employment/IP.

    (I’m not saying companies should do away with IP, just noting the gatekeeper aspect of it.)