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!
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.
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.
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.
> '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.)
I'm confused, the parent comment made me laugh while I was drinking a chai latte from https://summermooncoffee.com/pages/standard-menu-summer-moon... made with their moon milk and a shot of espresso ... I'm not sure what people find offensive/bad about that?
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.
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.
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,...).
With strict deadlines and OKRs to hit it wasn't really feasible for people to double up on projects.
> 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).
We did try this and it sounds good in theory but as the old saying goes 'two women can't have a baby in 4.5 months'.
In my experience (in this particular team and org) it would've simply been better to invest some time into documentation and suffer a short drop in productivity on a project when owners left.
I'm sorry to hear you couldn't make it work, but I can assure you that this approach works in practice. You don't get a child in 4.5 months, but you can get 2 children in 9 months.
I agree that not all environments are good at managing developers though (and that is probably a huge understatement).
Before the developer gets hit by the bus, it is cheaper to only have one developer on the project. For many managers, the economical analysis seems to end at this point.
Robustness and efficiency are fundamentally enemies, right? Unfortunately this means that the 'best' solution is often the least robust one that survives.
It kind of depends on how exactly the sharing mechanism works.
If you are in a place with code-review, the 2-person system allows one person to at least read the code that is being written as it's being written, so the genesis and reasoning behind such code might be a little more obvious.
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.
> 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).
That sounds nice in theory, but I've only ever seen it be a disaster in practice. It's like that mirror thing from Harry Potter. As soon as you actually try and make a maintainable code base, it starts going the other way.
The only way to truly optimise for onboarding is by writing the simplest, cleanest code possible. Everyone is already trying to do that by hiring the best devs they can. Any further efforts just look like more dependencies, more patterns, and more incidental complexity to act as guard rails in the pursuit of a newb-friendly codebase.
The end result is that new devs are productive at small and simple tasks, but big things take longer. Also, you're never going to find a manager that understands this trade off, so your new dev is going to be left in a terrible position trying to explain how they got so much work done in the first month when they knocked off all the small cards, but now the new feature that the business desperately needs has taken 3 months all by itself.
> 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.
Sometimes you can’t pay the owner not to leave. I’ve had two colleagues die. Another one had a stroke. Granted, I’m now around for like 20 years and a bit, things like that are rare, but no money in the world could have helped in these cases.
And sometimes people are just ready to move on. It doesn’t need to be because they’re underpaid or it’s a bad work environment. I was there and just wanted a change to a somewhat different type of work.
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".
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.
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.
All too often, code review amounts to no more than making sure there are no grievous mistakes. Management only cares about you completing your own work, and if reviewing the work of others slows you down, that's your problem. Time spent on code reviews have never counted toward mine or anyone else's performance. A bad PR making it to production certainly gets negative attention, so that's the aspect given priority. The incentives do not align to make code review a place for knowledge transfer.
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.
> 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.
Because all I have are anecdotes, but all of my anecdotes are on the side of shared knowledge being heavily biased towards safety and consensus building demanding a lot of time. That happens even between two people that mostly agree, and only increase with more people or different opinions.
Of course, some times a bias towards safety is exactly what you want. But on informatics projects, that happens very rarely.
Once in a long while two people can have complementary ideas that make them faster. But it tends to happen more often when one is the clear owner of the project and the other is advising. Shared ownership seems to almost kill those chances.
My anecdata (at multiple companies) supports their opinion.
What matters is that there is a clear owner who is the voice of final decision. In most cases there is no objectively better way to do something, so having a person who is a tie-breaker is beneficial. Of course, they must be involved in actual coding, doing code reviews of other people's code and similar. And other people must review the owner's and each others code.
But, having an owner is not the same as having a bus factor 1. There should be an owner, but other people should know the project and the codebase enough to step in at any given time, even as (temporary) owners if needed. And this is only possible if they actually work on the project, even if the approach that the team (/owner) decides upon is not what they would pick.
I don't know what you would consider evidence but I've looked in-depth at 200+ companies now and as far as I'm concerned this is no longer up for debate. But feel free to see things differently, that keeps me in business. Disaster recovery is a trick that comes with very high fees and what are you going to do about it?
Me and my peers sharing WW2 knowledge at the water-cooler probably considerably reduced productivity at one of my jobs. Your work on a part of the application that I have no interaction with is just about as relevant. Sharing knowledge just in case costs time.
Practioners of the 'hero' model also feel that they have it right. And that's all true right up to the point that they don't and then it is up to other people get them out of their mess.
See also: documentation, testing, refactoring and all the other goodies that keep a large codebase maintainable.
You can always tell the documentation and testing of a shared / non-owned codebase, just like the code: it’s incoherent. A series of random people make random get-in-get-out local changes with no awareness of non-local effects or any kind of design integrity. It’s like Twitch Plays Pokémon.
Given the comment elsewhere that having multiple people on a project wasn't possible because they'd not meet their goals then, presumably the old owners were more than busy with their new tasks and helping others wasn't a priority.
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 :)
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".
On the other hand, the "bus" scenario makes it very clear that it's the worst case that's a) not planned, b) no, you can't just call them anyways, even if its really really important and c) not something you can wait out until they return.
I would expect this to get responses like "you need to take your phone with you on your holidays" or "you should plan your holidays so that they don't happen at the time when the application is most needed".
In my experience, having the bus factor of one was not a problem for the company, it was a problem for me, because I needed to do a lot of negotiation about when to take my holidays. (After a few years I gave them the notice, and then it suddenly became a problem for the company.)
(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.
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.
I don't know if you would enjoy it, but keying off the idea of lifetime crafstmanship is the documentary film Jiro Dreams of Sushi[1], he was 85 at the time and ran a small but world famous sushi restaurant - no chain of stores, no growth at all costs, instead pursuit of excellence.
Quotes:
> Jiro Ono: Once you decide on your occupation... you must immerse yourself in your work. You have to fall in love with your work. Never complain about your job. You must dedicate your life to mastering your skill. That's the secret of success... and is the key to being regarded honorably.
and
> Jiro Ono: I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more. I'll continue to climb, trying to reach the top, but no one knows where the top is.
> I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more
Does he manage every aspect of his restaurant chain? Does he install all the plumbing and electrics? Does he wash all the dishes?
In 'software', it seems the 'skill' you're supposed to 'master' is always learning more of everything all the time.
I can not be a master of everything. I can not keep up with docker/k8s/security/design/css/UI/accessibility/i18n while continuing to 'achieve more' with SQL, server-side development, documentation, testing and more.
There are physical limits (x hours in a day, ability to focus and concentrate, and new 'things' constantly coming out).
I say this because as 'good' as I may be in the 'latest' in, say, 4 areas of development... I'm going to be judged harshly by certain groups of folks (team/hiring folks) because, for example, I may still be using bootstrap 5, or angular instead of react, or whatnot, regardless of if that's my focus or not.
I've fallen in love with some of my work, but there's a limit to how much I can do, and a limit to how much I can actually love. Some I just tolerate.
Well ageism is a bitch in our sector, but you certainly have to have in mind that maybe for the same reason past-entrepreneurs are frowned upon, if they know you don't need the money, they know they can't force you to do stuff you don't want...
It's a bit like when they want to know if you've family/responsabilities, I doubt it is to pay you a salary going with those, but more to gauge if you'll be a good slave or not...
Anyways, if I was in your position, I would do whatever I want, but without working for a company anyways, is not fuck you money (or attitude) at leaat, if you still have to obey the boss on all the bullshit right?
Best of luck!
PS: Oh now I saw your username, I've read you a lot arund here Chris, I think you're doing great with your own libraries/iOS stuff, I don't see why you might need to apply to a company, maybe you should start yours instead. You would make a good leader
I was a manager for many years (you can see many testimonials on my LinkedIN page). I just hated the job, although the consensus seemed to be that I was pretty good at it.
I do have a couple of companies, but they are more so I can access resources that are not available to individuals. I am currently working with a small 501(c)(3) (US nonprofit). It is a team, but there's only a couple of us tecchies, and I do most of the coding.
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.
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.
> 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.
The belligerence is that there’s very little benefit career-wise to being a good committee member on low-visibility committees. At best you get some nominal recognition, and at worst it’s a distraction from the things that actually do further your career. Nobody gets a gold star for that kind of work, but you do get big promotions when you can own chunks of work yourself (even when done poorly).
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.
We are talking about maintainers here, not developers or contributors.
And if a project stalls, he/she probably considers it done, in opposition to others. You can easily extend such a project under your own maintainance then, but then you must be capable of maintaining it.
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!
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.
GitHub stats -- if I remember right, if a project lasts more than ~1 year, the odds are it'll keep lasting, and you can redo the exercise every year or two
'few devs vs despite' matters a bit less when picking: it's the results + future expectation, irrespective of how :)
'how' is interesting . having observed dedicated oss devs owning a proj for years vs contracted devs working through tasks for their latest gig, I have unsurprising theories. Trickier is when going sustainable via revenue (which we do), how to keep that sense of ownership, vs usual employee code: industry increasingly adopts OSS practices like GitHub flow, but that misses much of the OSS maintainer magic.
I can tell you that, for myself, having one dev has definitely resulted in much higher Quality and a usable deliverable.
Most of my OSS projects are 1-file UI widgets (but with a lot more testing code than implementation code). I do, however, have a couple of monsters.
Because of my experience (which includes many mistakes), I am able to develop projects of a far more ambitious scope than the run-of-the-mill developer. The one that I'm working on now (not OSS), for example, is one that would usually be done by a heterogenous team.
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-...
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.
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.
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.
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.
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).
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.
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."
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!
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.
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.)
It was really a tragic occurrence, and very sad - Curtis was a great engineer. I think my drink tonight will be to him.
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.
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,...).
> 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).
We did try this and it sounds good in theory but as the old saying goes 'two women can't have a baby in 4.5 months'.
In my experience (in this particular team and org) it would've simply been better to invest some time into documentation and suffer a short drop in productivity on a project when owners left.
I agree that not all environments are good at managing developers though (and that is probably a huge understatement).
Simply said, that deadlines and OKRs don't account for bus factor.
If you are in a place with code-review, the 2-person system allows one person to at least read the code that is being written as it's being written, so the genesis and reasoning behind such code might be a little more obvious.
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.
That sounds nice in theory, but I've only ever seen it be a disaster in practice. It's like that mirror thing from Harry Potter. As soon as you actually try and make a maintainable code base, it starts going the other way.
The only way to truly optimise for onboarding is by writing the simplest, cleanest code possible. Everyone is already trying to do that by hiring the best devs they can. Any further efforts just look like more dependencies, more patterns, and more incidental complexity to act as guard rails in the pursuit of a newb-friendly codebase.
The end result is that new devs are productive at small and simple tasks, but big things take longer. Also, you're never going to find a manager that understands this trade off, so your new dev is going to be left in a terrible position trying to explain how they got so much work done in the first month when they knocked off all the small cards, but now the new feature that the business desperately needs has taken 3 months all by itself.
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.
But often there are some or all of those pieces missing, and so yeah, code review ends up being a bit shallow and performative.
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.
Because all I have are anecdotes, but all of my anecdotes are on the side of shared knowledge being heavily biased towards safety and consensus building demanding a lot of time. That happens even between two people that mostly agree, and only increase with more people or different opinions.
Of course, some times a bias towards safety is exactly what you want. But on informatics projects, that happens very rarely.
Once in a long while two people can have complementary ideas that make them faster. But it tends to happen more often when one is the clear owner of the project and the other is advising. Shared ownership seems to almost kill those chances.
What matters is that there is a clear owner who is the voice of final decision. In most cases there is no objectively better way to do something, so having a person who is a tie-breaker is beneficial. Of course, they must be involved in actual coding, doing code reviews of other people's code and similar. And other people must review the owner's and each others code.
But, having an owner is not the same as having a bus factor 1. There should be an owner, but other people should know the project and the codebase enough to step in at any given time, even as (temporary) owners if needed. And this is only possible if they actually work on the project, even if the approach that the team (/owner) decides upon is not what they would pick.
Oh, and we don't do ownership thing either.
See also: documentation, testing, refactoring and all the other goodies that keep a large codebase maintainable.
why?
I would expect this to get responses like "you need to take your phone with you on your holidays" or "you should plan your holidays so that they don't happen at the time when the application is most needed".
In my experience, having the bus factor of one was not a problem for the company, it was a problem for me, because I needed to do a lot of negotiation about when to take my holidays. (After a few years I gave them the notice, and then it suddenly became a problem for the company.)
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.
At 62, I can relate.
I think you might enjoy this short parable, as told by Alan Watts:
https://youtu.be/byQrdnq7_H0
Quotes:
> Jiro Ono: Once you decide on your occupation... you must immerse yourself in your work. You have to fall in love with your work. Never complain about your job. You must dedicate your life to mastering your skill. That's the secret of success... and is the key to being regarded honorably.
and
> Jiro Ono: I do the same thing over and over, improving bit by bit. There is always a yearning to achieve more. I'll continue to climb, trying to reach the top, but no one knows where the top is.
[1] https://www.imdb.com/title/tt1772925/
[2] https://www.imdb.com/title/tt1772925/quotes/?ref_=tt_trv_qu
Does he manage every aspect of his restaurant chain? Does he install all the plumbing and electrics? Does he wash all the dishes?
In 'software', it seems the 'skill' you're supposed to 'master' is always learning more of everything all the time.
I can not be a master of everything. I can not keep up with docker/k8s/security/design/css/UI/accessibility/i18n while continuing to 'achieve more' with SQL, server-side development, documentation, testing and more.
There are physical limits (x hours in a day, ability to focus and concentrate, and new 'things' constantly coming out).
I say this because as 'good' as I may be in the 'latest' in, say, 4 areas of development... I'm going to be judged harshly by certain groups of folks (team/hiring folks) because, for example, I may still be using bootstrap 5, or angular instead of react, or whatnot, regardless of if that's my focus or not.
I've fallen in love with some of my work, but there's a limit to how much I can do, and a limit to how much I can actually love. Some I just tolerate.
That is such a fantastic luxury position to be in.
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).
It's a bit like when they want to know if you've family/responsabilities, I doubt it is to pay you a salary going with those, but more to gauge if you'll be a good slave or not...
Anyways, if I was in your position, I would do whatever I want, but without working for a company anyways, is not fuck you money (or attitude) at leaat, if you still have to obey the boss on all the bullshit right?
Best of luck!
PS: Oh now I saw your username, I've read you a lot arund here Chris, I think you're doing great with your own libraries/iOS stuff, I don't see why you might need to apply to a company, maybe you should start yours instead. You would make a good leader
I was a manager for many years (you can see many testimonials on my LinkedIN page). I just hated the job, although the consensus seemed to be that I was pretty good at it.
I do have a couple of companies, but they are more so I can access resources that are not available to individuals. I am currently working with a small 501(c)(3) (US nonprofit). It is a team, but there's only a couple of us tecchies, and I do most of the coding.
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.
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.
The belligerence is that there’s very little benefit career-wise to being a good committee member on low-visibility committees. At best you get some nominal recognition, and at worst it’s a distraction from the things that actually do further your career. Nobody gets a gold star for that kind of work, but you do get big promotions when you can own chunks of work yourself (even when done poorly).
And if a project stalls, he/she probably considers it done, in opposition to others. You can easily extend such a project under your own maintainance then, but then you must be capable of maintaining it.
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!
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.
'few devs vs despite' matters a bit less when picking: it's the results + future expectation, irrespective of how :)
'how' is interesting . having observed dedicated oss devs owning a proj for years vs contracted devs working through tasks for their latest gig, I have unsurprising theories. Trickier is when going sustainable via revenue (which we do), how to keep that sense of ownership, vs usual employee code: industry increasingly adopts OSS practices like GitHub flow, but that misses much of the OSS maintainer magic.
Most of my OSS projects are 1-file UI widgets (but with a lot more testing code than implementation code). I do, however, have a couple of monsters.
Because of my experience (which includes many mistakes), I am able to develop projects of a far more ambitious scope than the run-of-the-mill developer. The one that I'm working on now (not OSS), for example, is one that would usually be done by a heterogenous team.
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.
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. :)
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.
> 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.
The number of people who, if hit by a bus and incapacitated, would allow an initiative to move forward.
…
On second thought, the average bus factor might be less than one
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).
Far too many organizations don't pay attention to operational risks...
[1] https://dsebastien.net/blog/2020-05-13-whats-the-bus-factor-...