The bus factor on a project is the number of people who would, if hit by a hypothetical bus, result in project catastrophe (e.g. stopped work, radically reduced ability to debug, etc).

If your bus factor is 1, that means when this guy below is clipped by the bus then you’re not doing much of anything on your project.

The bus factor is a bit morbid but neatly captures the risks of (a) technical know-how, (b) access, (c) and institutional knowledge in one metric.

• For example, if you have a team of 9 developers and only 1 has access to deploy to production, then you have a bus factor of 1.
• If you have a team of 5 and only 3 of them know the primary programming language, you have a bus factor of 3 - all thing being equal
• Etc. It’s a term used frequently in software projects but as you can probably deduce it’s not restricted to software. It could apply equally to the accounting department in a business where only one person is familiar with the books.

It may seem obvious that the solution is adding more people but it turns out this isn’t the solution. It may be a necessary step, but in and of itself it’s not sufficient. If floating your bus number is a priority there are some steps you can take to protect it.

1. Choose well understand and/or well documented components. This includes everything from programming languages and frameworks to third-party libraries, application server, databases, all the way to your deployment infrastructure. There are often very good reasons to choose esoteric components, but make sure your project meets these requirements first. Let’s consider this a baseline.
2. Maintain code and project documentation.
3. Automate. Automate. Automate. The brilliance of automating, from tests to deployment, is that you don’t have to know all the steps or their sequence, just how to start it off. Now, at a base level you really ought to understand what’s going on, but just to get started you don’t need to. So if you have your tests and deployment automated and you have only one “automation engineer” it may be tricky to make changes if that person leaves. However you won’t be dead in the water in the interim because you don’t need a person to run the automated tasks, hence “automated”. If automation sounds daunting substitute “scripting” and you’ll get 80% of the benefit.
4. Follow conventions (breaking as necessary). Each language, framework, project, and even domain has its own set of conventions, and following these makes it easier for other engineers - sometimes including future you - to understand what’s going on and how to make changes.
5. Follow “good” code practices. Encapsulating and separating concerns may seem like it has little to do with the bus factor, but it can mitigate it. If you can reduce from 3 to 1 the number of subsystems in the code a developer needs to understand to make changes in one place, then you reduce the impact that hypothetical bus has on your team.
6. Keep it simple. Simplicity isn’t always possible, but more complex solutions should be adopted only when they’re actually needed.
7. Maintain ownership. This doesn’t mean your team members shouldn’t be able to take ownership of the product in the sense of responsibility and direction. Rather, avoid exclusive ownership where only one team engineers has rights (of any kind) over one or more components. And in the event that you’re working with contractors or outside consultants (hey, that’s us!) make sure that you have ownership of where final work products are deployed. That means your source code control systems (for final product, at least) and your cloud/PaaS account. Do you have any questions about where to start automating your Django project?

Questions about how you can structure your Django app to keep it maintainable for future developers?

Hit that Reply button and ask.

Overly complicatedly yours,
Ben
 

More like this

• The Automator (This Old Pony #81)
• Novelty Seeking (This Old Pony #79)