“We should get our bus factor higher. It’s like 1.”
How many times have you heard this? I’ve been in too many meetings ending with a quip about bus factors. If you haven’t heard, bus factor is the number of engineers you can lose before a project stalls.
The bus factor on every project starts at 1 with a engineer taking lead of a system.
No matter how big the team, every engineer will be stretched maintaining and building new systems over the next few months. All my previous systems are still running. I can only keep so much context in my head and documentation can only capture the high level information.
Let’s be honest. Who here has perfect documentation and code comments? Or 100% test coverage? I don’t. I’ve frequently mentioned my primary directive was, “Don’t die” in the past which meant I was a single point of failure for the team.
I’ve dealt with a senior front-end engineer departing with no engineers available to grasp the entire system he constructed. Only thing I could do is step in and figure things out.
I have trouble allocating another engineer to work with me and understand the system deeply. Far more effective to have the other engineer build out features to meet incoming customer demand. As every engineer expands outwards on projects, I’ve experienced natural attrition or forgetting so the codebase has areas no engineer can maintain or have true context.
Then we’re dealing with a bus factor of 0.
I think there’s no avoiding the situation. With enough time and effort, as long as you have one senior engineer, this person can be sent into a codebase, get up to speed and figure things out.
I’d revise the thought process about bus factor. How long would your best engineer take to unravel a system and understand how everything works? If that’s too long, then begin thinking about training your engineers to trace a system quickly to reload context.
Leave a Reply