But what about the bus factor? (opens in new tab)

Glad to hear you're ok!

If you see enough companies over a long enough time these risks materialize with great regularity. Common reasons: burn out (probably #1), underpaid and undervalued so easily 'poached' (I don't like that term but don't have a better one),chronic illness, accidents, death. The latter is fortunately rare, two instances across 200+ companies across 15 years.

But the other ones happen frequently enough to take them serious. Most companies, unless they are very small are usually able to mitigate this to a very large degree without breaking the bank.

that should put the argument to rest, then. the bus factor is not a problem, the data shows that software developers survive being hit by a bus

Im sorry for your accident, but it its a funny thing to imagine the upper echelon sneaking into the hospital, to install eye-tracking software and a beamer on someone who is almost a cast-mumy. Imagine waking up after a accident, and a nervous intern sits besides you, instead of a loved one, trying to coax the passwords out of you before you pass.

I have a significantly less happy story in this regard: I had just started at a new company, and the lead engineer went off to a holiday. On the drive up, he was struck and killed by a truck. He had the credentials for a lot of things that were core to the company. We got access to the AWS Account without too much trouble, after two weeks to receive a paper letter from them, but a few things were a real pain in the ass to recover.

It was really a tragic occurrence, and very sad - Curtis was a great engineer. I think my drink tonight will be to him.

Sorry to say that, but it sounds like you got it backwards. The idea is not to remove the owner from the project, but to always have at least two people working on any project at the same time. Instead of 2 devs working for 2 months each on their own project, put them together on the first project for a month, then on the other project for the second month (simplified example, of course). They both work on their own tasks, but because they are familiar with the code and the project, they can review each others changes.

In my experience this works great. Context switching is a problem, but there are ways to minimize the impact (similar tech stacks, good work organization, clearly defined priorities,...).

Those aren't the only two options. You can try to get a team to develop systems that any other capable software engineer can pick up reasonably (such as via effective documentation, and reasonably maintainable nature of the code).

One of the biggest barriers to that (besides teams needing guidance on how to do it) is conflict of interest, which is a factor in the why. I started saying it upfront with founders at my last company, when speaking of who we wanted to hire, and how engineering should be done: "One of the jobs of an engineer is to 'document themselves out of a job'." Then I add something like "And the company has to realize that engineers who can and will do that are generally the best engineers, and extremely valuable to the company."

Though, if the engineers didn't trust management (e.g., not exhibiting analogous professionalism and duty, such only looking at near-term selfish impact), then I can't argue that engineers should go out of their way to be easier for a stereotypical anti-leader to treat poorly. I'd have to appeal to the engineer's sense of professionalism, or of some degree of duty to other team members. I'd also know it's probably only a stopgap, and to give them whatever support I can if/when they look elsewhere for a home for an unusually great engineer.

> Now I'm more convinced than ever that it's better to pay the price of an owner leaving

And it's also worth to pay the price to get the owner to not leave. So many companies seem to think penny-pinching is worth it, or only start giving out raises when actual attrition starts going up and many more people are already invisibly in the process of quitting.

Didn't you all do code reviews, project planning, etc.? These are all ways to get other devs involved and knowledgeable without explicit "you are now the owner".

> Productivity plummeted with every project. It was as if every owner of every project had left the team every quarter.

This only generally happens if you have an environment where every project is a snowflake and the ramp-up time per project is thus high. If you standardize on a stack, then the internal organization of your codebases starts to look pretty similar, and there's less for people to ramp up on when they switch projects. Kill resume-driven-development at your company.

The principle is sound, but your managers' way of implementing it is stupid. Productivity shouldn't go down as a result of knowledge sharing, it should go up.

That might work if just one project from each maintainers portfolio was shifted.

> It didn't really matter if the old owner was around to support.

why?

Ha, I'd be open to better names like this. I've seen someone talk to a client before about what a bus factor was when explaining why we were putting together a handover document and you could see the client visibly wince whenever "hit by a bus" was said. I usually go with "if one of us is on holiday".

(author here) That's a nice twist on the idea! You got me wondering whether a lottery win would change my plans. I love working on Vendure, I consider myself extremely lucky to be able to do so full time.

Death by committee is a real thing and it is a problem you need to architect around, but the answer to this is not to consolidate power. Instead, you build up a structure and system by which decisions can be made and a process that all members must abide by. If the core persons (the values of the bus factor) are unwilling to subject themselves to such a system and to work to design such a system, then the project will fail eventually under them, or it simply isn't such a great project.

Implementing such systems is absolutely a challenge as there is negative feedback to such things all the time; designing such a system, putting persons in place whose job it is to enforce the process, putting persons in place to weigh in on if an action or decision matches the letter and spirit of the process, all of this take a lot of discipline and maturity from the participating members; I've done this with several orgs now, and even with backing from the VP level, at best I get belligerent participants, and truly I cannot tell if their resistance is that they don't like the decisions we make, or if they just don't understand the process and want the ability to complain to someone directly.

Most of the issues you get with multiple stakeholders is because of a lack of discipline within the org; people who are too used to "just doing things" without really considering the full consequences of actions in favor of just doing what they want. You see this in basically every collective project, not just programming projects too. I consider it a win if we have people begrudgingly participating, but ultimately participating.

Do you have any examples? In my experience projects with only one or two developers just move too slow and often stall for months or just die because they have other things to do in life.

Many times (not departed as in departed, just - not there any more).

Could of hard-won experiences:

- under no ciscumstances should you do the rewrite until you understand the whole domain, which is not until you know the codebase inside-out. And even then it's probably a very bad idea ("Yes but the old version allowed us to do X...").

- start with business requirements: make sure you understand what people expect from the system, how they use it, what it does at high level. Sit with users and watch them use the app!

- tests: do not touch the code until you understand the existing tests or, if tests do not exist, until you have covered the code with your own, preferably integration or end-to-end tests (unit tests are great, but they don't guard you against integration failures, which is what you want to be protected against here too)

- skim the documentation if it exists, but don't put too much faith in it as it is probably out of date. Same for comments.

- slowly start fixing bugs, cleaning up some code... whatever you do, make sure it is covered with tests.

- good luck. :)

Yes, multiple times. And this can happen at a well managed company. To some extent it's my niche. I'm not a coder (I program, but don't touch our product code base), but an industrial scientist, and these projects often involve multiple disciplines such as mechanical and electrical as well as code. My process is to start by just trying to figure out the theory of operation, and identify what is usually a single critical path of data through the code.

Right now I'm looking at a relatively small code base that was written by an engineer in the embedded systems team. The original authors are retired. It's generously documented, and a pleasure to read. This makes my life easier, but also less of a hassle for the un-retired engineers on the receiving end of my requests for help. I don't know about commercial coding, but adding comments and documentation can help a non-specialist work their way through code if they have some decent programming background.

The full re-write can happen if the departed developer is an entire departed business, e.g., an acquired company comes with code that is obfuscated to the point of being Goedel-undecidable ;-)

Science isn't flawless. There's the so called reproducibility crisis. I think what helps science is that nothing of lasting value depends on a single critical path from data to results, but is reinforced by looking at things from multiple angles. For instance we'd still trust general relativity had the Eddington experiment never happened. And scientists such as myself are always looking for ways to make our own work more open and reproducible. In my work, Jupyter Notebook has been a game changer.

Yes, I did multiple times. I had not done full rewrite, because there was zero reason to do it. Nor time for that matter. The thing I took over was typically developed over a lot of time, doing it again would take a lot of time again.

> However, many senior developers recoil at the thought of quality documentation

There is no such a thing as quality documentation. An individual here and there is able and willing to write one. Average developer is not. And I don't even blame them, it is in fact skill and job occupation on itself to be able to do so.

Developers are not even trained in how to write good documentation. There are no processes to check, test and review documentation.

You’re right, on the other hand I’d guess that the median bus factor is 1 and a better metric as this isn’t going to be normally distributed.

Count only core maintainers and I'd be surprised if it was above one, yeah. Companies ensuring they have no core maintainers by spreading everyone out essentially has a bus factor of 0 all the time, even on new projects.