Raise your bus factor: 3 easy practices to implement on your team

// 01.07.2015 // Culture

A team’s Bus Factor is the number of developers who must be taken off a project in order for all forward progress to cease indefinitely. Bus Factor measures a team’s resiliency — its ability to deliver in the face of unexpected resource challenges.

Consider the effects of a key team member taking a two-week vacation on a remote island, or being stuck on a broken-down train in a tunnel for several hours, during which unexpected updates to dusty legacy software are required. The remaining team members must be able to pull through without input from the affected teammate, and that teammate must be able to get back up to speed quickly upon their return.

Much like the foundation of a good network, the goal for a Bus Factor-aware team is to create a reliable team structure despite the unreliable nature of life.

I work on the Apps Team at MediaMath, and our team is particularly vulnerable to a low Bus Factor. We build lean, single-purpose web apps and partner integrations that provide our clients with power-user functionality on our platform. Because of the nature of our projects, we tend to work more or less independently on distinct projects of varying length and complexity. As a result, our short-term, project-by-project Bus Factor is almost always less than two developers.

Our team goal is that any project can continue with a small number of developers, and that languishing projects can either be placed at the end of the remaining developers’ queues, or braided in to their existing workload. Much like the design of a distributed system, our team continues to execute its mission despite particular nodes being unreachable.

We are well aware of the risks of a low Bus Factor, so we have focused a substantial amount of time on creating mechanisms that enable our team to measure up.

Legacy Code Lunch & Learns

Twice a month we host a modified code review over lunch, where we discuss particularly challenging or interesting pieces of code we’ve come across, whether by our own hand, uncovered in external libraries, or excavated from legacy code. Most times we spend half of the meeting doing a “Deep Dive” into a particular code base. Our projects are typically small enough that 30 minutes is enough time for an overview (without going into too many domain particulars), and a deeper look into some of the more valuable chunks of code.

These reviews are especially helpful for learning about older projects that none of us have seen before. One developer becomes more familiar with the legacy project before presenting it to the others. Any of us may be called upon to add a feature or tackle some dusty edge-case bug on our legacy projects, so these sessions have been incredibly helpful for reducing the amount of time it takes to get up to speed on our oldest projects. There is also the additional benefit of letting us reflect, as a group, on the design decisions of the past and evaluate them based on our new domain understanding and more recent development practices.

Open Door Policy

An expected source of challenge for our team is that we tend to work independently on a slew of projects, each of which might be at any stage of the development process. This is the most pressing cause of our tenuous Bus Factor. Our best tool to avoid it is to employ an “Open Door” policy. Any “in-need” developer can tap whoever they think is most able to help, and they’ll work through the problems together. Often all that’s needed is a good rubber duck session, with an occasional daytime-TV-worthy four-hands-one-keyboard dive into the code.

Informal Domain Knowledge Overviews

Other knowledge-silo situations have more to do with domain knowledge than with the code itself. For example, our integration with Facebook’s ad exchange, FBX, may only have one active developer at a given time, but anyone may be tapped to handle a support ticket. Given the depth of domain knowledge required to continually deliver on this product, questions are frequent and the answers often complex.

Our solution is to host informal domain knowledge overviews whenever a question of sufficient complexity is posed. Everyone on the team is invited to attend, and share knowledge of the domain. As more people become familiar with the domain, more are able to contribute, and the discussions become fuller, richer, and more helpful.

As a result of this mechanism in particular, we have a team culture that allows developers to take on support tickets for projects they may never have directly worked on. Our projects may only take one or two developers to build, but they benefit greatly from having four to five developers to support them. This makes support less time-consuming for each developer, and our wide spectrum of greenfield projects is freed to move forward without significant roadblocks.

Check back next week for part two of this series, where I will discuss best practices for addressing documentation and building coding standards.

A Picture of Michael Porter


Developer on the Apps Team Michael Porter is a developer on the Apps team at MediaMath. He has a keen interest in the wetware side of software development, and believes a developer’s greatest strength should be their team. Before joining MediaMath, he worked in theatrical lighting design (of all things), followed by a handful of engineering roles at early-stage startups in NYC. Michael has a BA in Literature from Bard College.

Leave a Reply

Your email address will not be published. Required fields are marked *