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)
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.
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.
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.
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!
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:
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:
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...