4 ms·

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.

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

hobs 1y ago
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 1y ago
  >> 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.
the_af 1y ago
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).
- scarface_74 1y ago
  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?
  - TuringNYC 1y ago
    > 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 1y ago
      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 1y ago
        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 1y ago
      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 1y ago

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 1y ago
>> 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.

the_af 1y ago

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

scarface_74 1y ago
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?
- TuringNYC 1y ago
  > 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 1y ago
    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 1y ago
      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 1y ago
    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.