[TuringNYC]

The Bus Factor was an issue long before LLM-generated code. Very few companies structure work to allow a pool of >1 individuals to understand/contribute to it. What I found is -- when companies are well structured with multiple smart individuals per area, the output expectation just ends up creeping up until again there is too much to really know. You can only get away from this with really good engineering management that specifically tries to move people around the codebase and trade-off speed in the process. I have tried to do this, but sometimes pressure from the stakeholders for speed is just too great to do it perfectly.

Shameful plug, i've been writing a book on this with my retrospective as a CTO building like this. I just updated it so you can choose your price (even $0) to make this a less shameful plug on HN: https://ctoretrospective.gumroad.com/l/own-your-system

I dont think anyone has the perfect answer, yet, but LLM-built systems arent that different from having the system built by 10 diff people on eLance/Upwork/Fiverr...so the principles are the same.

[the_af]

The Bus Factor was indeed an issue before LLMs, and in fact it's a jargon term that has been in use since forever.

What TFA is arguing is that never before we had a trend towards Bus Factor zero. Before, the worst was often 1 (occasionally zero, of course, but now TFA argues we're aiming for zero whether we're aware or not).

[TuringNYC]

True, but when the bus factor is 1, it might as well be zero -- soon you end up with employees (or contractors) who legitimately want more compensation realizing their critical nature. I totally sympathize from the employee's perspective, esp if the 1-factor means they cannot take holiday. Really, it is the company's job to control the bus factor (LLM or human) -- it is good for both the employee and company in the long run.

[the_af]

Agreed, it's the company's job to control the Bus Factor, that's a given. I think TFA's author worries that instead of controlling it, we're now aiming for zero (the worst possible factor).

[scarface_74]

Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

[the_af]

A Bus Factor of 1 has always been construed as high risk; that's why the term exists after all. Companies sometimes mitigate it, sometimes not, but in general they are vaguely aware it's a risk.

A Bus Factor of 0, especially as an implicit goal, seems doubly worrisome! Now it's a goal rather than a warning sign.

[TuringNYC]

> Is there really a large difference between 0 and 1 when the average tenure of a software developer is 3 years or less at any given company?

Spot on. 1 might as well be zero. Totally unfair to the worker also, who now cannot take time off.

[scarface_74]

When I was an architect for startups between 2016-2020 doing mostly green field development using new to the company AWS technologies, I made damn sure that any knowledge was disseminated so I could both take a vacation without being interrupted and I could “put myself out of a job”.

I considered it a success when I realized a company doesn’t need me anymore and I can move on and talk about what I did at my next interview in STAR format.

[TuringNYC]

Agree, and also, promotion is hard if you are too tied to a specific system. Diagonal cross-department promotion becomes especially hard if you are a single point of failure.

[the_af]

But a Bus Factor of 1 has always been considered high risk. Sometimes companies take the risk, but that's a different issue.

This is precisely why the term "Bus Factor" was invented: to point out when it's 1, because it's both high risk to the company and unfair to the dev that cannot go on vacation or extended time off.

[hobs]

Yes, its very much a goldfish problem, where work needed grows to fill what is possible, not what is advisable or good. The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process, and generally it just makes everyone lazy and deliver stuff at the last second anyway, not use the additional time to make something polished.

[TuringNYC]

>> The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process

I solve this by sufficient compartmentalization with good inter-component interfaces. Worst case, you excise part of your system and rebuild. Possibly you can take the schema and docs and rebuild with an LLM :-)

I talk about this in my upcoming book on the topic (link above.) Most good systems are rebuilt 3 or 4 times anyway.