How many software developers would have to leave a project to make development come to a halt? That number is the bus factor. The macabre meaning behind the bus factor is the number of developers that would need to get hit by a bus to halt development (but it's often lighter to think about members winning the lottery, not that anyone who knows about statistics would actually play the lottery).
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.
How do you increase the bus factor of your projects?
- Write documentation
- Resist Toolchain Sprawl – no or few bespoke frameworks.
- Corollary: pick common frameworks if you can (see: Getting to Market with Rails and Developer Network Effects)
- Comment your code effectively
- Make it dead easy to contribute. Many of the suggestions to grow your open source project can be applied to making onboarding easier for internal projects.
- Code review culture
It's important to note that many employees are solving to reduce bus factor (rightly or wrongly). Here's some biases to correct for:
- Developers are biased towards new and exciting frameworks to build their skills and pad their resume. Look for opportunities to let developers grow that are outside architecture choices.
- Developers are biased against writing documentation because they are not evaluated on documentation. Make communication a key tenet of engineering culture.
- Developers are biased against intensive code reviews because they slow velocity of changes, and developers are evaluated on changes (and by extension, their velocity). Keep the bar high and consistent.
- Developers are biased towards automation. This is generally good, but over-optimization can lead fragile systems. Automation can be a burden (your integration tests are too long)