But what about the bus factor?

I am the developer which literally got hit by a bus, AMA!<p>I miraculously survived the accident with many broken bones and got back to work in about 3 months. And now it puts a smile on my face whenever I see the term &quot;bus factor&quot;. And it probably scared our company quite a bit because I was the only software engineer, so definitely a bus factor of 1. But our company is mainly not a software company so they managed to survive with minimal support from me until I got back.<p>So yeah, it can happen! Be careful when crossing the street!

Two years ago my team (then) was maintaining 15 or so projects in production, and landing 3-4 more every quarter. Each project was de facto owned by one person who did the bulk of the work on 2-3 projects.<p>After a team member left and a new maintainer had to step in to maintain an unfamiliar code base, our new EM decided that the bus factor must be raised across all projects. So every quarter we shifted responsibilities to new projects and had someone else take over ownership - the idea being that the previous person would still support and we&#x27;d not be in trouble in case someone left. That&#x27;s not what happened though.<p>It didn&#x27;t really matter if the old owner was around to support. Productivity plummeted with every project. It was as if every owner of every project had left the team every quarter.<p>Now I&#x27;m more convinced than ever that it&#x27;s better to pay the price of an owner leaving if and when it happens, rather than try to prevent or mitigate that risk up front. The productivity costs are far too high for most software products.

I prefer to call it the Lottery factor. How many people have to win the lottery and retire for a project not to have a maintainer? It&#x27;s a little more positive :)

He forgot to mention the Urban bus factor anti-pattern. (comparable to Brooke&#x27;s Law. The more you add to a project, the longer it will take)<p>The lower the bus factor, the better the project. Raising the bus-factor to fight the bus-factor will lead to worse projects.<p>You can easily see that with popular open source projects. The more committers and managers you get, the more fighting, re-architecturing for the worse and harmful meta discussions how a project should be led. Eg COC. Good projects are usually led by 1, max 2. Everything above that is critical. If the one is hit by bus, another one can take over eventually. But not before. And it might need 10 years to find the one.

Has anyone taken over a project from a departed developer? What were the steps that you took? I would wager most people will reach for the full rewrite which we know is something that you should never do. <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;06&#x2F;things-you-should-never-do-part-i&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2000&#x2F;04&#x2F;06&#x2F;things-you-should-...</a><p>However, many senior developers recoil at the thought of quality documentation and prefer “self documenting” code which doesn’t cover the why and thought process behind the code. This makes something other than a full rewrite daunting. Even with the best self documenting code you will continue to be surprised in large projects. The full rewrite allows the rewriter to reexperience the process but it’s very expensive and may be worse than the starting point.<p>If science and engineering were done like software, so much knowledge would be lost. We know that there are giants in the space of Science, Einstein’s work was published and continued on by others to this day. I think the difference is that in science the motivation is to learn and teach, whereas in software people are pressed to create almost exclusively. We won’t publish papers, but to get closer to science, I think it’s necessary for solo developers to keep a development journal as has been done by scientists for some time.<p>I mention nuts and bolts engineering, because in engineering, the best are usually mentoring others, catching mistakes, and teaching rather than actually doing the legwork. That’s an alternative angle to fight the bus factor.

Also not to be forgotten is the inverse bus factor:<p>The number of people who, if hit by a bus and incapacitated, would allow an initiative to move forward.

nitpicking: the <i>average</i> bus factor cannot be 1 unless there are as many projects without maintainer as projects with two or more maintainers<p>…<p>On second thought, the average bus factor might be less than one

Almost every one of my projects has a bus factor of 1.<p>That’s OK, because most were written for my own use, in other projects.<p>The one project that I wrote, that is used by thousands, around the world, has been taken over by a new team, and I hardly have anything to do with it, anymore. It took ten years, of running the project alone, to get to that place.<p>In all my projects, these days, I develop them as if they are major corporate initiatives. I believe this makes it easier for others to use and understand (I also tend to use the MIT License).

I think a good approach for a company betting the farm on an external project that may stop being maintained (or may decide to head in a different direction) is to basically become expert in the project themselves. They should probably pin the version and be fully aware of new changes, and ready to modify the project to suit their needs.

I wrote about this a while ago [1].<p>Far too many organizations don&#x27;t pay attention to operational risks...<p>[1] <a href="https:&#x2F;&#x2F;dsebastien.net&#x2F;blog&#x2F;2020-05-13-whats-the-bus-factor-of-your-team-and-how-to-increase-it" rel="nofollow">https:&#x2F;&#x2F;dsebastien.net&#x2F;blog&#x2F;2020-05-13-whats-the-bus-factor-...</a>

I don’t know if