
Bus factor - caffeinewriter
http://en.wikipedia.org/wiki/Bus_factor
======
a2tech
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.

------
graeme
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)

------
zwieback
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.

~~~
humanrebar
Bus coefficient?

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

------
ctdonath
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).

------
csmatt
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.

------
munchor
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.

------
nathanb
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.

------
asogi
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?

~~~
1781
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.

~~~
avz
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"

~~~
thaumasiotes
> 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.

------
stefek99
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...](http://webmasters.stackexchange.com/questions/55554/what-are-the-
steps-to-ensure-that-if-you-die-your-hosting-domain-will-live-on)

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

------
ceronman
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](https://twitter.com/voidspace/status/435449949342679040)

