The bus factor

In this case, “bus” is used literally.  The bus factor measures risk to a project based on how many project members could be “hit by a bus” before the project fails. 

In software development, this typically refers to the expertise of each developer in a team or organization, and ensuring the knowledge of the systems built and maintained for the organization are spread amongst the entire development team.  Just like adding redundancy to servers helps ensure High Availability, it is important to have a level of redundancy amongst the people developing the systems that power the business’s operations, so the business isn’t left scrambling if that key person leaves.

This is something my colleagues and I are always aware of, and are continuously working to improve.  At a team level, we try to ensure a majority of the team members are familiar with all aspects of the projects we work on.  We may have our individual areas of expertise, but we also make sure we aren’t the lone knowledgeable person.  We pair program, do code reviews, and collaborate on the design of the solution.  We bounce ideas off each other and share insights.  Across teams we rotate among projects and take time on knowledge transfer of a new system to the next team to work in it.  There may be an initial barrier of entry that slows down the progress of the team, but we recognize the long term benefits.

“But don’t I lose job security?”

Maybe.  It depends on whether you’re working in the right environment.  Does your employer recognize the importance of technology to their business?  Do they recognize the risk of cutting corners in their IT department?  If the company would replace you with a junior developer as soon as you shared the knowledge of the systems you’ve built, do you really want to work there in the first place? 

If you’re working in the right place, your job security comes from your ability to solve the tough challenges presented to you, from your expertise in the tools and frameworks used, and from you’re ability to use those skills collaboratively with others.  In fact, it’s to your employer’s benefit that you distribute as much knowledge as possible so you can continue to provide the business the most value you have to offer, by helping the business continue to grow by developing new solutions, rather than being stuck as the only one able to maintain the systems already developed.

The most effective way to become indispensable is by being good at your job

Take the time to learn new technologies, read blogs, and stay up to speed on the tools you use.  Read The Clean Coder.  Become a professional software craftsman, rather than a code monkey.  These things will do far more for your job security and usefulness than being the person who will leave a gaping hole in the knowledge pool if “hit by a bus”.

One thought on “The bus factor

  1. Pingback: Developer’s toolbelt: debugging production issues–part 1 | Ryan Hauert

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s