9 ms·

But what about the bus factor?

65 points by tough 5y ago

temptemptemp111 5y ago
Imagine being the guy who was in charge of AMD/Intel backdoor private key & instruction backups! To all of you who belittle the issue of "management engines" being transparent blackbox OSs that you "could reverse engineer if you really wanted to, but it is probably nothing sinister."
ChrisMarshallNY 5y ago
Almost every one of my projects has a bus factor of 1. That’s OK, because most were written for my own use, in other projects. 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. 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).
eckesicle 5y ago
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. 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'd not be in trouble in case someone left. That's not what happened though. It didn'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. Now I'm more convinced than ever that it'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.
- gregn610 5y ago
  That might work if just one project from each maintainers portfolio was shifted.
- _dark_matter_ 5y ago
  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".
  - thrower123 5y ago
    There's no substitute for actually working in a code-base.
  - rhipitr 5y ago
    Does a code review provide the necessary time for someone unfamiliar with the code base to understand all of the business logic that will be affected and where this new addition sits within that hierarchy? Code reviews have never seemed contextually rich to me.
    - mikepurvis 5y ago
      I think the theory is that for code review to be its best, it sits on a contextual pyramid composed of reviewed design docs, pair programming, standups, and all the rest of it. That the "reviewers" are not hearing about the background, motivations, alternatives that were considered, broad implementation choices, etc etc for the first time when the PR goes up. But often there are some or all of those pieces missing, and so yeah, code review ends up being a bit shallow and performative.
  - eckesicle 5y ago
    Yes of course, but code reviews do not always tend to transfer a lot of context.
  - bluesnowmonkey 5y ago
    If they don’t already feel ownership, it’s easy to just approve PRs without looking at them critically. Why deal with confrontation trying to uphold code quality for a project they don’t really own? I find people don’t pay attention in reviews unless their personal success is tied to the long term success of the project.
alexchamberlain 5y ago
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's a little more positive :)
- s_severus 5y ago
  (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.
  - ChrisMarshallNY 5y ago
    I have “retired” (but not out of choice -no one wants to hire us “olds” -I stopped looking at 56). These days, I work harder than ever, for far better quality product, than I ever did, when a corporate drone. I don’t make a dime; but it’s never been about the money, for me. I really love designing and shipping product. There’s a special joy that comes from architecting and finally delivering a complete software project. I consider it a craft, and take great pride in my craftsmanship. Personally, I think it’s absolutely insane for corporations to deliberately ignore and insult folks like me. I was quite upset, when I first ran into it, but, upon reflection, I have to admit that it was probably the best thing that ever happened to me. If my hand had not been forced, I would have kept on working, making other people money, and never having the joy that I experience, every day. Definitely worth it. Would buy again.
    - jacquesm 5y ago
      > but it’s never been about the money That is such a fantastic luxury position to be in.
      - ChrisMarshallNY 5y ago
        Definitely. I worked hard to get here. Saved 25-40% of my money, while working. Lived real "low on the hog." It's "f**k you money." I just thought that the idea was for me to say "f**k you" to employers; not the other way 'round (which is what happened).
ZuLuuuuuu 5y ago
I am the developer which literally got hit by a bus, AMA! 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 "bus factor". 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. So yeah, it can happen! Be careful when crossing the street!
- jacquesm 5y ago
  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.
  - ZuLuuuuuu 5y ago
    That is a good point. Fortunately, I do feel like I am valued in this company. But at that time, I was relatively new in this company and I have moved from another country to work at this company. So I was eager to prove myself to them and was doing overtime regularly, which might have played a role in my carelessness (or is "reverie" the correct word?) at the split second of the accident.
  - tikhonj 5y ago
    You could say "underpaid and undervalued so they leave" which places the agency in the right place and covers strictly more situations. You don't need to be actively recruited in a market with pay differentials this large.
  - wolverine876 5y ago
    > 'poached' (I don't like that term but don't have a better one) How about just saying that they left? 'Poached' puts the agency in the hands of their new employer, as if the person was cattle and their job change was due to cattle rustlin'. (Not that some management doesn't look at it that way.)
nomdep 5y ago
nitpicking: the average bus factor cannot be 1 unless there are as many projects without maintainer as projects with two or more maintainers … On second thought, the average bus factor might be less than one
- Jensson 5y ago
  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.
- twobitshifter 5y ago
  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.
twobitshifter 5y ago
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. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... 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. 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. 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.
- analog31 5y ago
  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.
projektfu 5y ago
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.
dpeck 5y ago
Also not to be forgotten is the inverse bus factor: The number of people who, if hit by a bus and incapacitated, would allow an initiative to move forward.
elderlydoofus 5y ago
I don’t know if
dSebastien 5y ago
I wrote about this a while ago [1]. Far too many organizations don't pay attention to operational risks... [1] https://dsebastien.net/blog/2020-05-13-whats-the-bus-factor-of-your-team-and-how-to-increase-it https://dsebastien.net/blog/2020-05-13-whats-the-bus-factor-...
rurban 5y ago
He forgot to mention the Urban bus factor anti-pattern. (comparable to Brooke's Law. The more you add to a project, the longer it will take) The lower the bus factor, the better the project. Raising the bus-factor to fight the bus-factor will lead to worse projects. 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.
- CorrectHorseBat 5y ago
  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.
  - lmeyerov 5y ago
    most oss projects are 1-2 devs over many years, so easier to enumerate those that aren't ;-) ex: D3 was/is really mike bostock. the exception there has been, afaict, the GIS packages and maybe changed over last 1-2 years ex: we use 'got' for JS HTTP, and most dev is 1-2 devs moving quickly, and community for QA ex: caddy felt the same, but that may have also changed post acquisition interestingly, all 3 support plugins/galleries for occasional non core contribs the article was clever to observe that most commercial sw does bump up bus factor in a funny way: sustainable bump.. but typically goes up by only a little!
    - CorrectHorseBat 5y ago
      How can one know these projects run so good because there's only a few devs and not despite? I was more thinking of an example of a project that failed because it had too many developers. An example of the opposite I thought of immediately is neovim. The vim dev didn't really want too much changes so the neovim fork took of, and eventually vim development sped up too.

65 points by tough 5y ago

Imagine being the guy who was in charge of AMD/Intel backdoor private key & instruction backups! To all of you who belittle the issue of "management engines" being transparent blackbox OSs that you "could reverse engineer if you really wanted to, but it is probably nothing sinister."

ChrisMarshallNY 5y ago

Almost every one of my projects has a bus factor of 1. That’s OK, because most were written for my own use, in other projects. 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. 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).

eckesicle 5y ago

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. 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'd not be in trouble in case someone left. That's not what happened though. It didn'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. Now I'm more convinced than ever that it'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.

gregn610 5y ago
That might work if just one project from each maintainers portfolio was shifted.
_dark_matter_ 5y ago
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".
- thrower123 5y ago
  There's no substitute for actually working in a code-base.
- rhipitr 5y ago
  Does a code review provide the necessary time for someone unfamiliar with the code base to understand all of the business logic that will be affected and where this new addition sits within that hierarchy? Code reviews have never seemed contextually rich to me.
  - mikepurvis 5y ago
    I think the theory is that for code review to be its best, it sits on a contextual pyramid composed of reviewed design docs, pair programming, standups, and all the rest of it. That the "reviewers" are not hearing about the background, motivations, alternatives that were considered, broad implementation choices, etc etc for the first time when the PR goes up. But often there are some or all of those pieces missing, and so yeah, code review ends up being a bit shallow and performative.
- eckesicle 5y ago
  Yes of course, but code reviews do not always tend to transfer a lot of context.
- bluesnowmonkey 5y ago
  If they don’t already feel ownership, it’s easy to just approve PRs without looking at them critically. Why deal with confrontation trying to uphold code quality for a project they don’t really own? I find people don’t pay attention in reviews unless their personal success is tied to the long term success of the project.

alexchamberlain 5y ago

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's a little more positive :)

s_severus 5y ago
(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.
- ChrisMarshallNY 5y ago
  I have “retired” (but not out of choice -no one wants to hire us “olds” -I stopped looking at 56). These days, I work harder than ever, for far better quality product, than I ever did, when a corporate drone. I don’t make a dime; but it’s never been about the money, for me. I really love designing and shipping product. There’s a special joy that comes from architecting and finally delivering a complete software project. I consider it a craft, and take great pride in my craftsmanship. Personally, I think it’s absolutely insane for corporations to deliberately ignore and insult folks like me. I was quite upset, when I first ran into it, but, upon reflection, I have to admit that it was probably the best thing that ever happened to me. If my hand had not been forced, I would have kept on working, making other people money, and never having the joy that I experience, every day. Definitely worth it. Would buy again.
  - jacquesm 5y ago
    > but it’s never been about the money That is such a fantastic luxury position to be in.
    - ChrisMarshallNY 5y ago
      Definitely. I worked hard to get here. Saved 25-40% of my money, while working. Lived real "low on the hog." It's "f**k you money." I just thought that the idea was for me to say "f**k you" to employers; not the other way 'round (which is what happened).

ZuLuuuuuu 5y ago

I am the developer which literally got hit by a bus, AMA! 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 "bus factor". 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. So yeah, it can happen! Be careful when crossing the street!

jacquesm 5y ago
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.
- ZuLuuuuuu 5y ago
  That is a good point. Fortunately, I do feel like I am valued in this company. But at that time, I was relatively new in this company and I have moved from another country to work at this company. So I was eager to prove myself to them and was doing overtime regularly, which might have played a role in my carelessness (or is "reverie" the correct word?) at the split second of the accident.
- tikhonj 5y ago
  You could say "underpaid and undervalued so they leave" which places the agency in the right place and covers strictly more situations. You don't need to be actively recruited in a market with pay differentials this large.
- wolverine876 5y ago
  > 'poached' (I don't like that term but don't have a better one) How about just saying that they left? 'Poached' puts the agency in the hands of their new employer, as if the person was cattle and their job change was due to cattle rustlin'. (Not that some management doesn't look at it that way.)

nomdep 5y ago

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

Jensson 5y ago
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.
twobitshifter 5y ago
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.

twobitshifter 5y ago

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. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... 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. 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. 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.

analog31 5y ago
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.

projektfu 5y ago

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.

dpeck 5y ago

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

elderlydoofus 5y ago

I don’t know if

dSebastien 5y ago

I wrote about this a while ago [1]. Far too many organizations don't pay attention to operational risks... [1] https://dsebastien.net/blog/2020-05-13-whats-the-bus-factor-of-your-team-and-how-to-increase-it https://dsebastien.net/blog/2020-05-13-whats-the-bus-factor-...

rurban 5y ago

He forgot to mention the Urban bus factor anti-pattern. (comparable to Brooke's Law. The more you add to a project, the longer it will take) The lower the bus factor, the better the project. Raising the bus-factor to fight the bus-factor will lead to worse projects. 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.

CorrectHorseBat 5y ago
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.
- lmeyerov 5y ago
  most oss projects are 1-2 devs over many years, so easier to enumerate those that aren't ;-) ex: D3 was/is really mike bostock. the exception there has been, afaict, the GIS packages and maybe changed over last 1-2 years ex: we use 'got' for JS HTTP, and most dev is 1-2 devs moving quickly, and community for QA ex: caddy felt the same, but that may have also changed post acquisition interestingly, all 3 support plugins/galleries for occasional non core contribs the article was clever to observe that most commercial sw does bump up bus factor in a funny way: sustainable bump.. but typically goes up by only a little!
  - CorrectHorseBat 5y ago
    How can one know these projects run so good because there's only a few devs and not despite? I was more thinking of an example of a project that failed because it had too many developers. An example of the opposite I thought of immediately is neovim. The vim dev didn't really want too much changes so the neovim fork took of, and eventually vim development sped up too.