DEV Community

Scott Harrison
Scott Harrison

Posted on • Updated on

How to increase your Bus Factor?

Most developers will be familiar with the Bus Factor.

The "bus factor" is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel.

The problem is it isn't always a simple thing to overcome in a development team whether it be someone on holiday, off sick or any number of things that mean someone isn't around to share their knowledge.

What is your approach to increasing your Bus Factor? How do you make sure that the whole team is brought up to speed on projects without reducing capacity too much?

Top comments (7)

Collapse
 
dmfay profile image
Dian Fay

I think the single best thing you can do for the bus factor is to use a pull request review model. If nothing makes it into the codebase without at least x other people signing their name to "I understand this change well enough to know that it does what it says it does" then that's x other people who at bare minimum have a head start on picking up the slack on bus day.

The trick is solving for x. On smaller teams, you might have to have everyone review each change. If there are more people, then it's possible to share the load around by requiring maybe two or three approvals. This also lets you play to people's strengths and specializations -- if you have a couple of frontend experts, they'll be able to clear UI pull requests faster than the team average. And if someone is interested in breaking into the frontend, getting on the review list (even if their approval isn't strictly required) is a solid learning opportunity.

Collapse
 
ben profile image
Ben Halpern

As a matter of lowering the bus factor on items that can't be so cleanly reflected in the code, we have a few "heads up" and "minutes" channels to send out signals about certain relevant activities/discussions that only one or two people took part in. We've found this super valuable.

Collapse
 
dfockler profile image
Dan Fockler

Our team has talked about only approving a pull request when you are sure you understand the implications of the PR. We just started testing this out so we're still seeing how it goes. It's a balancing act between getting things done quickly and making sure everyone understands what changes are happening and why.

Collapse
 
scottharrisondev profile image
Scott Harrison

Code reviews are something I never really considered as helping increase bus factor as I've always seen them as primarily a code quality improvement tool but you make a pretty good point, no reason why it can't do both.

I guess it would be best to have as you say, front end or back end devs reviewing their respective specialities on each project that way you get maximum number of eyes on each project without having a labour intensive review process.

Thanks!

Collapse
 
lukewestby profile image
Luke Westby • Edited

I would develop a ride-sharing app, named like Unter or Dryve or something, that systematically undercuts public transit funding, eventually crippling the transit system and eliminating all of the buses in the city. With zero buses the bus factor goes to infinity!

For real, though, we:

  • Create an expectation that complicated code will have comments, which we try to maintain through code review
  • Frequently pair program across teams
  • Rotate engineers onto new teams every couple of quarters
  • Post important changes in #x-changes Slack channels and announce them again in an all-hands meeting every Monday morning
  • Heavily discuss and document process and decisions, with an increasingly permanent set of places to write. Slack -> Discourse, Dropbox Paper -> Wiki, Engineering Blog.
Collapse
 
einenlum profile image
Yann Rabiller • Edited

I wrote a series of articles on the topic. You can check it here.

Here are the few points that seem important to me in the end:

  • Do systematic code reviews (but it's not enough)
  • Give complex tasks also to the juniors but help them
  • Stay close to the domain of your client
  • Use high level tests reflecting your domain
  • Write explicit code
  • Detect a lack of shared knowledge as soon as possible, and write down everything in your repository/code. Stop this oral culture: act as if your private project was an open source project on which every unknown developer should be able to collaborate
Collapse
 
lighta971 profile image
Aurel

Hi Scott, did you improve your own approach since the article ? Take a look at my recent post dev.to/lighta971/how-to-make-all-d...