Hacker News Reader

Comment by pestatije | Hacker News Reader

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

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

That seems self correcting over a relatively short horizon.

You would think so, but the quality of software doesn’t seem to be improving.

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.

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.

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.

you can change the name to 'lottery factor' if being hit by a bus is politically impractical at your organization.

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.

I've always called it getting hit by the lottery bus

I mean depending on the payout for the inevitable lawsuit...

You give people ownership over bigger subsystems over time, basically.

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.

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.

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

The corporate term is "healthy redundancy".

Reply on news.ycombinator.com