Bus factor | Hacker News Reader

Bus factor

en.wikipedia.org

I've lived through this situation-I lived, but the product died. My boss at the time was the primary developer (really, only developer) of our healthcare web app. He had been hacking on it in one for or another for over a decade. Guy up and has a stroke one morning getting out of bed and dies. Database documentation has no bearing on reality, all of his reporting code was uncommented. All of his programs were 8 character max camelCase names with no (to me) bearing on their function. Product basically died with him-I've kept it running in a zombie fashion, but all new features or even creating new reports is impossible.

This works with income sources too. There was a time when 90% of my recurring income depended on one guy. I used to worry about the bus factor.

Now that I diversified, I don't need to worry.

I'm meanwhile trying to reduce the bus factor in my own business, which is just me + outsourcers. I'm documenting what I do and creating processes, and am going to see a lawyer to make a will.

I'm only 28, but if anything happened where either I died or couldn't work, I'd want to be able to hand things off without it being an unusable mess.

(reducing my own bus factor also makes it easier to outsource)

I've always preferred the term "bus number". Factor seems to imply multiplication but bus number is really a kind of non-linear subtractive thing.

Bus coefficient?

Multiplication could plausibly be involved if the cost to the project compounds with the number of lost team members.

Several companies (IBM included), even countries (Poland of late), learned the hard way to not put the "bus factor" people all on the same bus (or airplane).

This came up in a meeting the other day where I asked someone to define technical debt. I instantly remembered the first company I worked for calling it 'being hit by the baby bus'. They were combining the concept of the 'bus factor' with the fact that 2 of the senior people on the project (out of 6 of us total) had babies within months of one another.

This is an especially relevant concept in Open Source. It's hard to describe how important writing documentation, clean well-commented code and gathering a community of programmers is for big open source projects.

At elementary OS, we work hard to keep our bus factor healthy, and it should also become a priority on other projects as, unfortunately, we keep coming across "dead" open-source projects because the lead (and sometimes sole) developer of the project had to move their focus to another project or to real-life work.

I wonder, though, if there's an easy way to "measure" a given project's bus factor and would love to know more about it.

The story from a different perspective: on my old project, there was a bus factor of 1...and I was that 1.

When I was a new college hire, I thought that would be a good situation. And while it has its perks, it also has many downsides. But the biggest one came when I decided it was time for me to move on.

I wanted to stay with the company and move to a new project. It seemed like a great fit, the new project wanted me...but the director of the old organization told me I had to stay responsible for the old product for 3-6 months before I could formally transition. I had to basically threaten to quit in order to have that number reduced.

If you are in this situation, make sure that either the company is working to increase the bus number and give you some more resources or that the company realizes your importance and compensates you accordingly. I didn't quite realize that my employer saw me as being the critical engineer until after trying to leave. In hindsight it's obvious, but since I started right out of college as a junior developer under people who knew everything about the problem space, my mindset was never "I am the expert", even long after those actual experts had left.

If a team has n people, the loss of any of whom would halt the project, does that mean that the bus factor is 1/n?

Nope, from the wp article: "The bus factor is the total number of key developers who would need to be incapacitated [...] to send the project into such disarray that it would not be able to proceed"

So: you would like the factor to approach n.

You're correct under the definition in WP.

Note that often (e.g. when comparing bus factor of projects of different sizes) it makes sense to normalize by dividing by the size of the team in which case the answer to asogi's question is "Yes, normalized bus factor is 1/n"

Shouldn't that be b/n (where b = bus factor, n = team members)?

> when comparing bus factor of projects of different sizes [] it makes sense to normalize by dividing by the size of the team

Consider two projects, a one-man project with a bus factor of, obviously, 1, and a 100-man project with so much redundancy within the group that the bus factor is an impressively robust 50. The standard bus factor immediately tells us that the big project is much much less fragile.

The "normalized bus factor" you describe (1 for the solo project, 1/2 for the huge project) perversely tells us that the big project is much more fragile, in that it will be disabled by the loss of 50% of the team, while the solo project will only go down after a full 100% of the team is eliminated.

Why does it make more sense to count redundancy by "percentage of the team, whatever size the team might be" rather than by "number of setbacks before project failure"? In general, the bigger team really does make the project more robust, not less robust.

Hm. I wonder if there's a way to distinguish between "If this particular person gets hit by a bus, we're screwed" versus "If any of these n people get hit by a bus, we're screwed" (which is a lot worse).

How about looking at the number of people who must be removed in order to bring the bus factor down to 1? We can call it the "bus co-factor" :). With the bus factor we're picking the most critical people first, and removing the least number of them; with the bus co-factor we're picking the least critical people first, and removing the greatest number of them.

There's probably already some name and many theorems in graph theory for both of these ideas.

You can treat it like a reverse big-O notation. Your figure out the bus factor for each sub-task/system in your project (this is the risk factor) and then determine the priority of each sub-task/system. If a GUI is "easy" or low priority for your project, one GUI person doesn't mean your project has a bus factor of 1. But if networking is critical and you have one person that understands the novel telecon protocol stack you're using, that's a bus factor of 1.

Assuming you are micro independent software vendor (MISV) or one man web shop (OMWS), how do you reduce your Bus Factor?

http://webmasters.stackexchange.com/questions/55554/what-are...

(longer term I want to put myself out of the equation)

Also note the Inverse Bus Factor: ”how many developers have to be hit by a bus before a project starts to proceed smoothly?”

https://twitter.com/voidspace/status/435449949342679040

Reply on news.ycombinator.com