4 ms·

This is termed "the bus factor", and the best way to deal with it is prevention, or "increase the bus factor": https://en.wikipedia.org/wiki/Bus_factor https:/

This is termed "the bus factor", and the best way to deal with it is prevention, or "increase the bus factor": https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor

uticus 4y ago
Tried really hard to avoid the term "hit by a bus" but yes this is exactly what is meant. But looking for something more specific - like, how is that specifically planned out in a project? How does being "open source" affect the plan, vs closed? Or even, what is the specific plan for if Linus gets hit by a bus? Hold a vote? Heir-apparent, decided by Linus himself? Split the responsibilities evenly? Also, to ask from another viewpoint, what historical case studies are there? Seems like in the open-source community at least everyone is young enough that this hasn't been much of an issue yet.
- eatonphil 4y ago
  You give people ownership over bigger subsystems over time, basically.
  - lightbendover 4y ago
    I have rarely seen more than one or two people understand how all those sub-systems work together in any org I have ever been in. So few people look over their own fence.
- baq 4y ago
  you can change the name to 'lottery factor' if being hit by a bus is politically impractical at your organization.
  - qntmfred 4y ago
    I've always called it getting hit by the lottery bus
    - Mezzie 4y ago
      I mean depending on the payout for the inevitable lawsuit...
  - sebzim4500 4y ago
    Yeah but for many projects the bus factor and the lottery factor can be quite different. Unless your employees are miserable, they will probably still be reachable to answer short form questions after winning the lottery, even if they don't actually work for their full notice period.
itsmemattchung 4y ago
You'd be surprised to see how often this occurs. Sometimes, for piloted projects, especially during the prototyping phase, a single point of failure—or, as pestatije pointed out, "bus factor" — sometimes inevitable. So you either run the risk of that person being no longer available, or, even during the initial stages (which can be expensive in human resources), partner up, right from the beginning.
jesuscript 4y ago
The corporate term is "healthy redundancy".
emidln 4y ago
I've also heard "Key Person Risk" recently for the same concept.
ChrisMarshallNY 4y ago
The only issue that I see with the Tech Industry obsession with "bus factor," is that companies insist on replacing "rockstar" developers, with really (and I mean really) low-skill developers. i.e., Linus needs to be replaceable by a JS programmer, right out of bootcamp. This leads to truly awful codebases, "dumbed down" to the lowest common denominator. I have had people tell me not to use advanced Swift capabilities, because "a JavaScript programmer couldn't understand it." I'm a fairly advanced Swiftie, but not as leet, as some. One of the really nice things about my current [unpaid] gig, is no one telling me that my code is "too complicated," or "too strange." Yeah, it's strange. Learn to live with it...
- JonChesterfield 4y ago
  That seems self correcting over a relatively short horizon.
  - ChrisMarshallNY 4y ago
    You would think so, but the quality of software doesn’t seem to be improving.
Tarragon 4y ago
I have been hit by a bus. Survived obviously. At work I've been added a 2nd technical contact and security contact for several projects because "you're less likely to be hit again". I think, but I'm not 100% sure, that is being done in a joking manner.
- nixgeek 4y ago
  HR: “Next year we’re going offsite as part of annual performance discussions”. “We will be traveling via bus to a Dave & Busters nearby”. “Those of you who meet expectations will board the bus at 8AM to go have fun, thank you for your contributions to the company in this past period”. Ominously unstated is what happens to those who didn’t meet expectations.

This is termed "the bus factor", and the best way to deal with it is prevention, or "increase the bus factor": https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor

uticus 4y ago

Tried really hard to avoid the term "hit by a bus" but yes this is exactly what is meant. But looking for something more specific - like, how is that specifically planned out in a project? How does being "open source" affect the plan, vs closed? Or even, what is the specific plan for if Linus gets hit by a bus? Hold a vote? Heir-apparent, decided by Linus himself? Split the responsibilities evenly? Also, to ask from another viewpoint, what historical case studies are there? Seems like in the open-source community at least everyone is young enough that this hasn't been much of an issue yet.

eatonphil 4y ago
You give people ownership over bigger subsystems over time, basically.
- lightbendover 4y ago
  I have rarely seen more than one or two people understand how all those sub-systems work together in any org I have ever been in. So few people look over their own fence.
baq 4y ago
you can change the name to 'lottery factor' if being hit by a bus is politically impractical at your organization.
- qntmfred 4y ago
  I've always called it getting hit by the lottery bus
  - Mezzie 4y ago
    I mean depending on the payout for the inevitable lawsuit...
- sebzim4500 4y ago
  Yeah but for many projects the bus factor and the lottery factor can be quite different. Unless your employees are miserable, they will probably still be reachable to answer short form questions after winning the lottery, even if they don't actually work for their full notice period.

itsmemattchung 4y ago

You'd be surprised to see how often this occurs. Sometimes, for piloted projects, especially during the prototyping phase, a single point of failure—or, as pestatije pointed out, "bus factor" — sometimes inevitable. So you either run the risk of that person being no longer available, or, even during the initial stages (which can be expensive in human resources), partner up, right from the beginning.

jesuscript 4y ago

The corporate term is "healthy redundancy".

emidln 4y ago

I've also heard "Key Person Risk" recently for the same concept.

ChrisMarshallNY 4y ago

The only issue that I see with the Tech Industry obsession with "bus factor," is that companies insist on replacing "rockstar" developers, with really (and I mean really) low-skill developers. i.e., Linus needs to be replaceable by a JS programmer, right out of bootcamp. This leads to truly awful codebases, "dumbed down" to the lowest common denominator. I have had people tell me not to use advanced Swift capabilities, because "a JavaScript programmer couldn't understand it." I'm a fairly advanced Swiftie, but not as leet, as some. One of the really nice things about my current [unpaid] gig, is no one telling me that my code is "too complicated," or "too strange." Yeah, it's strange. Learn to live with it...

JonChesterfield 4y ago
That seems self correcting over a relatively short horizon.
- ChrisMarshallNY 4y ago
  You would think so, but the quality of software doesn’t seem to be improving.

Tarragon 4y ago

I have been hit by a bus. Survived obviously. At work I've been added a 2nd technical contact and security contact for several projects because "you're less likely to be hit again". I think, but I'm not 100% sure, that is being done in a joking manner.

nixgeek 4y ago
HR: “Next year we’re going offsite as part of annual performance discussions”. “We will be traveling via bus to a Dave & Busters nearby”. “Those of you who meet expectations will board the bus at 8AM to go have fun, thank you for your contributions to the company in this past period”. Ominously unstated is what happens to those who didn’t meet expectations.