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.<p>Now that I diversified, I don't need to worry.<p>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.<p>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.<p>(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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.
Assuming you are micro independent software vendor (MISV) or one man web shop (OMWS), how do you reduce your Bus Factor?<p><a href="http://webmasters.stackexchange.com/questions/55554/what-are-the-steps-to-ensure-that-if-you-die-your-hosting-domain-will-live-on" rel="nofollow">http://webmasters.stackexchange.com/questions/55554/what-are...</a><p>(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?”<p><a href="https://twitter.com/voidspace/status/435449949342679040" rel="nofollow">https://twitter.com/voidspace/status/435449949342679040</a>