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.

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

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

> An individual who ended up owning a particular piece of a codebase will be incentivized to obfuscate and obscure their code in order to maintain full control over it.

That's fair, but I've also seen an orthogonal effect happen maybe more often where an engineer structures code just naturally in a way that fits them well, but is poorly understood by others. Not due to the incentives of maintaining control or job security. But simply because the engineer wasn't talented at making good code for other humans, and there were very few incentives to write code good for other people, at least early on in the design.

It's also that sometimes they stay on that codebase because they weren't the best engineer, and all the better ones move on to bigger things.

Or they were the best and the ones who left were the worst ones. The argument can be made both ways.

Or they are a junior or expert beginner engineer that thinks good code means checking off as many design patterns as possible. I've seen this a lot.

Maybe I've just dealt with good cultures but I find this a bit cynical. Normally when there have been too few people who knew a section of code, it was because:

- The area of code has a high ramp up, high risk, and few new work incentivizing ramping up on it.

- The curse of knowledge makes it hard for the person familiar with the code to know what is needed for others to understand it. Incentives are needed to encourage learning by others to force the maintainer to better understand how to explain things. This isn't a judgement on the person in their general inability to write code for humans nor is it about obfuscation.

You need incentives for the maintainer helping others to learn. AND you also need incentives for the others to start learning.

I am living right now this situation where I am the maintainer of a large chunk of code, I would like to have at least a second pair of eyes looking on what I do, but the others are all busy with their own tasks and no one learn from the others.

> We should also not be quick to blame the individual for perpetuating this

This part at least, I agree with. Whenever I see code like this it is a symptom of a larger product development issue.

- unreasonable deadlines

- overpromising to external clients

- no coding standards (enforced by linter and code review)

- no automated testing

- no code review process

- using new languages/technologies without first gaining some experience about best practices

Early on, a startup definitely needs engineers that are going to work autonomously, cut corners as needed, not be a perfectionist, etc. The technical cofounder/CTO/team leader should still be setting up a culture of high quality code. Coding styles and some automated testing make it easier to move quickly and ramp up new team members or for old team members to circle back to old code.

I've never met an engineer who was deliberately bad to ensure their job security. Most of the time the developer is just plain bad at their job, and any job security that results from writing reams of spaghetti code is just a happy accident.

> It's job security and furthermore if it's a valuable piece of the product then it can keep praise and rewards centered on you.

That's part of it, but training people is also very difficult. If you know a system well it takes a day to add some feature, but it takes a few days of frustration to train someone else.

If those are actual numbers (a day versus a few days) then that should be an incredibly easy decision. A few extra days is nothing compared to doubling your capacity to deal with problems in that system!

That is a few extra days for one task. 6 months later you'll still be training the person, though the overhead will still be lower it still will be slower than doing it yourself. Then the person might leave and you start all over again.

This seems like the common mistake of trying to optimise for individual efficiency at the expense of the rest of the system.

Yes, overhead will be higher, but since capacity also will be higher, cycle time will go down much more (non-linear effect) and you'll extract important value and feedback out of the tasks sooner, easily paying for further capacity improvements.

IME, this isn't so black and white.

In some situations, that engineer has a very strong mental model of the business domain they're modelling in code. It's a model forged by years of experience in the domain.

The model has complexities, but they are generally a minimal set necessary necessary to span the domain.

At first sniff, new engineers might find the code overengineered. It's a Chesterston's Fence dilemma. Except, in this circumstance, you have the builder there to explain the fence, and IMO it's wrong to assume malfeasance (obfuscating for control), when there are other contributing factors.

IME, the way to resolve this ambiguity is paired programming and communication. After the 2nd or 3rd session, the mental model should prove to be transferable or not.

Never attribute to malice that which can be adequately explained by incompetence.

Bus-factors are usually an organizational smell. What I mean by that, even if the individual is doing it on purpose (in order to control people in their gate keeper role or to have heroic tales to tell) the failure is the organizational structure and culture who allows empire building to happen in the first place.

I don’t work in this kind of environment. What is an example of a common team based incentive?

Team-based incentives are not particularly common yet, though they are growing in popularity. It's pivotal that a team has some choice in who they are teaming up with in order to align motivations and incentives to achieve. A simplistic incentive is an autonomy based award. If a team completes a project ahead of schedule then they can spend the remainder of the allotted time to work on whatever they please. Sort of make your own 20% time. You can see how hard this is to get right though because if you let the product managers set schedules then they'll make the deadlines too short. If only the engineering team sets the schedule and is incentivized to come under schedule then they'll consistently over-estimate. Requires trust and balance between the team and the stakeholders.

All that said, when you talk to really high-performing teams many of them will say that they value just continuing to get to work with that same set of individuals. It's a reward onto itself to get to work with people whom you really enjoy working with.

First, and I really want to point this out. The author's sentance you are quoting doesn't have fully correct english and due to that is missing meaning. You're reading into it what you want.

Second, applying the assumption they are obfusicating code to maintain control or ensure job security paints a lot of people with a very, very wide brush. If you asked why or spent time understanding why, then you'd get a lot closer to the truth of whatever the situation happens to be.

Third, Arthur Schopenhauer is attributed with the statement "Talent hits a target no one else can hit; Genius hits a target no one else can see." High performers tend to hit targets nobody else can see and that tends to be a very disorienting experience for all involved because systems end up behaiving in unexpected ways. Some people call it code obfusication, some people call it forcing people who are looking to break things to understand what they are doing before they do it; both are forms of organizational dysfunction which is pandemic in the industry.

Subtly demonizing these people as "inhuman", or as you are doing right now, painting them with a wide brush, illustrates one of the serious problems that high IQ and high performance staff face. Namely, they get scapegoated and harassed by groups of people.

At one org I found a bug causing 8 figures a year in inventory shrink caused by 2 lines of SQL Code that had been there for 10+ years; a contractor had come in, implimented a fix, and nobody had ever questioned it. Millions of dollars of inventory were being stolen by staff. Now imagine how disorienting that is to the entire end to end org. Believe you me, the c-suite wanted me gone after that and not because I wasn't doing a great job, but because I was fixing organizational issues that made them look bad and they wanted that stopped. They hired a high performer, encouraged it, and then when it got too bad for them, they got rid of them.

It is fully possible that some of these situations exist where there's a toxic, narcissistic fascade being sold to maximize profit. It happens. But I doubt that is the norm.

Is this an issue of organizational incentives? It's an issue with organizational structure, not recognizing people for who they are, and not aligining staff's interests because in this world we have this f'd up idea that we're just here to make money for shareholders or be the ATM machine for ownership. If running a company as pageantry makes them money, then they do not care.

This is why many high performers often create a niche money-making product that doesn't take up a lot of their time to get cash out of, then move on to working on other things that make them happy.

Why waste the effort if people don't care?