[TheDong]

In my experience, the far more likely explanation for a bus-factor for an area of code is not that they want it to be that way, but because the organization has stretched them and other coders thin enough that it's hard to fix that.

An organization can get surprisingly far with a huge number of bus-factors, and doing a learning-by-fire session whenever someone burns out and quits.

If the engineer who's a bus-factor on that project is willing to help others learn and recognizes tech debt but isn't given time to fix it, that points to organizational issues to me, not to any engineer being bad nor attempting to have job security.

[gnat]

"An organization can get surprisingly far with a huge number of bus-factors". So much this.

Some managers see high bus factors as a sign of success: "we are a team of specialists: it's so much faster to give a problem to X than to have Y come up to speed on X's code base."

This, of course, sets X up for (invisible?) pressure not to take holidays or get sick. And because problems don't occur evenly across your code base, chances are that one of your devs gets far more bugs to fix than the others. And because the pressure at your org is to go fast, there WILL be bugs to fix. "Testing is too slow", etc.

[Viliam1234]

If you don't care about the bus-factor, you can have 10 projects with 10 developers. Actually, even more than that, because one developer can work on multiple projects in parallel, or at least have one active project and one or more mostly stable projects where they are the only person doing maintenance.

But of course with 10 projects you will need at least 15 managers...