>I’ve never thought of it being used maliciously, it’s for visibility. It would be a shitty manager that would use it that way and if they’re already shitty then this tool won’t change that.

You are a member of the intelligence community of a country, let's call it Tussia, which has been locked out of the leading kernel for military hardware in the world. Let's call that Kinux.

You know that the guy down the office has started a project to fork that kernel for your countries own internal usage. You're an over achiever and want a promotion before he gets one. You call acquisitions for 8 female agents with special training for intimacy with nerds, you also make a back up call for 8 doses of polonium in case the agents aren't successful.

In case you think the above is fiction I know a CEO of a unicorn startup who got the first part of the treatment when he was looking for seed funding.

> I’ve never thought of it being used maliciously, it’s for visibility. It would be a shitty manager that would use it that way and if they’re already shitty then this tool won’t change that.

I've had three jobs where Pluralsight Flow was introduced. At two of them, the managers immediately started using the metrics for feedback, performance reviews, employment decisions. At the third, the developers saw this coming a mile away and refused to engage with or evaluate the tool.

Unfortunately, the absurd pricing of these tools means that people who approve them have to get some sort of ROI. Since they don't have a good way to measure productivity/output/knowledge silos, they instead turn to "Well Jose had less PRs this week..."

Excellent points about visiblity, as long as you can keep it in that domain.

But this always lurks in the near shadows:

>>I’ve never thought of it being used maliciously, it’s for visibility. It would be a shitty manager that would use it that way

Therein lies the problem, on both sides. It would just become another arms race, as the developers would use it to identify and move into target project areas/components to get themselves on the list of un-fireable workers. Ideally, the workers would ensure work together to ensure that the truck_factor was zero, i.e., none of them could be fired.

Of course all of this rapidly becomes a (nearly)complete waste of time, proving the blogger's friends original point: >>"My coworkers said it would immediately hit Goodhart’s Law. "

An outside firm might use this to help a company conduct layoffs. Manager could be amazing

> Some developers fear fungability, they think that that one system only they know is job security. I see it the other way, I see that as a technical risk, but also a thing that might be keeping a great engineer from working on more important projects. Or the way to work on something else when you get fed up with that one system you hate.

I don't fear fungibility - if a place doesn't want me there I don't want to be there either.

I dislike idea of fungibility because it creates huge overhead and avoids using talented people to full potential - because they are not fungible.

In some places that's warranted - but in others - the process overhead is far greater risk to your project success than bus factor.

I know a def who was denied a transfer and promotion because he couldn’t easily be backfilled.

Spoiler he left company within 3 months

> Some developers [...] think that that one system only they know is job security

"You can't be promoted if you can't be replaced."

> Some developers fear fungability, they think that that one system only they know is job security

And this is pragmatical for an employee who's primary goal is not optimizing Amazon's income.

I've spent my entire career trying to make myself and every other cog-head as replaceable as possible. Part of this is because that's the job in large parts of digitalisation, but another big part is because it's annoying to deal with knowledge silos. One of the reason we use Typescript for a lot of our back-end stuff is because it's the one language that our small team has to know. This means our front-end dev can go on a vacation and actually disconnect because other people can cover. It also means it's less of a pain when someone changes jobs.

It has never once been an issue and I think fungability is a part of any healthy system. I spent a few years on the other side of the table, and one of the first lessons you learn in management is that everyone is replaceable and that's solely a matter of cost. Because of this, high levels of knowledge may also work against you as management will likely work on reducing the risk you present. Another thing you'll learn is also how random layoffs can be, especially if they happen for economic reasons.

That being said. I avoid working at places with these silly metrics. The more red tape you put in the way of good work the less likely I'll want to work with you. There are a lot of reasons for this but the primary one is that these sort of things tend to create work cultures which just aren't good for productivity and quality as people "game the metrics" instead of doing good work.

At the end of the day the engineer has a valuable skill and you're the one telling them they need to be more replaceable. You're the enemy. Of course you're going to think the tools that let you dehumanise your employees at scale are good things.

This is an increasingly common problem: two layers, both trying to utilise the entire machine by parallelising by the number of CPUs/cores, and so the inner layer gets N² threads/processes. Being quadratic growth, this means that the problem becomes worse the more CPUs you have. With 32 cores, 32² = 1024, though in practice Parallel was told 8 so it’d cap out at only 256 index-pack processes. But that’s a lot of memory needed to support that, especially given that it’s doing no good.

The solution is for only one of the two layers to parallelise.

—⁂—

Given that you talked about pack.threads, here’s its description from `man git-config`:

> Specifies the number of threads to spawn when searching for best delta matches. This requires that git-pack-objects(1) be compiled with pthreads otherwise this option is ignored with a warning. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. Specifying 0 will cause Git to auto-detect the number of CPUs and set the number of threads accordingly.

> Temporarily setting pack.threads to 1 (via git config)

Or just use `git -c pack.threads=1 clone`: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

Thank you, didn't know this. I'll add it to the article.

> The Bus Factor is how hard your team would suffer if you - or anyone else on the team - got hit by a bus.

> Ideal Bus Factor for all team members is 0. This might sound counter-intuitive at first, almost like "make everybody expendable", but it's quite the opposite and kind of the point.

I've always heard bus factor described in the inverse fashion, as in "how many people would need to get hit by a bus for the project not to be able to continue", with the optimal number being the same as the number of people on the team. It sounds like the idea is the same, but I'm surprised to find out that the number people to convey the concept isn't always the same.

> Teams should be good enough that they are a) autonomous and b) there are no mysteries. In the ideal state, everyone understands how everything works. New employees should hit the ground running and be able to produce value immediately. Departing employees should feel comfort in knowing that there are no unknowns.

I've worked on projects where we had engineers who were one of a countable handful of people in the world with their particular skillset.

The bus factor was most certainly 1 at that point.

> More importantly, a 0 BF is a reflection of simplicity. The software, its build/test/deployment pipelines, documentation, and support, should all be cohesive and coherent.

For projects which push the frontiers of what is possible, simplicity isn't an option. (Granted these are a small % of overall software projects that exist!) When something has never been done before, you aren't worried about keeping the code As Simple As Possible, you are worried about how the hell you can even do this particular thing.

I'm not saying the code should be low quality! However sometimes doing hard stuff involves complex code, and maybe a couple generations later people have figured out design patterns so the hard stuff can have less complex code, but that may be a decade down the line!

If you only build things that are so simple that anyone can understand the code on day one and you don't need any domain knowledge, then what is your value proposition?

If the most complex thing you can build is a todo-app, then I think you don't produce much value to society.

Agreed. People who are good at their jobs and confident in what they do actively try to make their Bus Factor as low as possible. If you have a high Bus Factor that means your employer keeps you because of what you have done in the past, not your potential to do great stuff in the future.

> Ideal Bus Factor for all team members is 0.

The military thinks that way. They expect to lose people and keep going.

Thanks, this is the key info I was looking for here.

Yep, we have a tech lead who has great code writing abilities. But he has terrible leadership, feedback, etc skills. He would be much better as a senior dev instead of a tech lead. I can't imagine how miserable his team would be if he was a manager.

If you think that code review is “management” then that’s very very concerning.

I didn't write it in 2015 when my coworkers asked me not to.

I do want to see if open source software I use has spread the knowledge to increase survival.

I refused the jerk move!

Kudos to you. Bullshit metric.

How is this ironic?

Also, we did document how we arrive at the number: https://www.olafalders.com/2021/06/30/cpan-bus-factor/

People who win the lottery give their 2 weeks notice, and you can call them on the phone afterwards if you really have to.

People hit by a bus disappear immediately.

It's just not the same thing.

A good employee will want to hand off his projects and take questions, but you need to be ready if he can't.

Ye using sudden death as an eupheism for changing employer leaves a bad taste.

It is like when people complain about people using sports metaphors. I say that at least it is not military metaphores.

Also, there is usually no handover anyways. So the suddeness factor is not that important.

I'd argue that it is easier being hit by a bus so you have to factor that.

It's just gallows humour.

To me "lottery factor" seems overly po faced and pious.

I prefer bus factor because... memento mori.

Don't know anyone who won a lottery big, or got hit by a bus, but know several people who quit cause of crypto riches.

These days the "politically correct" phrasing is:

"Lottery winner"

Someone wins the lottery.

(I am old - I start with the poor bus driver scenario - but then try to inject the new phrasing into the conversation - as typically I am the only technical person on my team and they begin to rely on me for EVERYTHING)

i worked a software job that sometimes involved literally going to the busyard to debug on-board equipment. people at that job used the phrase attrition risk rather than bus factor because the latter was just a little too "real".

I imagine the employer limps on with the current codebase and/or is spending beaucoup bucks to rewrite the codebase while still using the old one.

True! The original 2015 article I found on Linux Weekly News had comments that worried about that https://lwn.net/Articles/651384/

I think Linux is safe because everyone uses it.

Could happen?

mclare published the other half of the blog post with nice graphs a few hours later: https://mclare.blog/posts/the-bus-factor/

I'd like to build a tree of open source dependencies and find out which parts need the most knowledge spreading.

This is what I was most interested in with this project (especially in light of the https://opensourcepledge.com/). We didn't run it against any new libraries, so it would be interesting to see the state of the most starred libraries.

While it is the platonic ideal for operating an existing service, this is also a great way to kill your velocity if you are an early-stage project which needs to deliver results yesterday, and/or pivot on a dime, in order to stay funded...

Over 30-ish years of work, I’ve lost about 0 coworkers without warning or transition to lotteries or similar events, and more than a few (whether permanently or for an extended period) to unexpected sudden death, injury (traffic related being particularly common), or other unheralded misfortune (law enforcement involvement, on a short out of country trip and then encountered visa issues, whatever.)

“Bus factor” is a more realistic reflection of the threat model, and resonates with experiences anyone who has been working more than a short time probably has more than “lottery factor”.

The implications are different. There has to be a high euro sum you can offer to get someone who won the lottery to still brief a colleague. You can throw money at a dead person all you want but that will not have the same result. It is a sudden end in knowledge that can not be restored with time or money (like running out of lottery funds)