Ask HN: Contingency plans for a lead dev no longer avail?
What are typical ways larger projects handle a situation where a person closely associated to the project is no longer available?
For example, Linus for Linux, or Guido for Python, if they were suddenly and unexpectedly unable to perform their duties.
47 comments
[ 2.5 ms ] story [ 104 ms ] threadhttps://en.wikipedia.org/wiki/Bus_factor
But looking for something more specific - like, how is that specifically planned out in a project? How does being "open source" affect the plan, vs closed?
Or even, what is the specific plan for if Linus gets hit by a bus? Hold a vote? Heir-apparent, decided by Linus himself? Split the responsibilities evenly?
Also, to ask from another viewpoint, what historical case studies are there? Seems like in the open-source community at least everyone is young enough that this hasn't been much of an issue yet.
Unless your employees are miserable, they will probably still be reachable to answer short form questions after winning the lottery, even if they don't actually work for their full notice period.
This leads to truly awful codebases, "dumbed down" to the lowest common denominator. I have had people tell me not to use advanced Swift capabilities, because "a JavaScript programmer couldn't understand it." I'm a fairly advanced Swiftie, but not as leet, as some.
One of the really nice things about my current [unpaid] gig, is no one telling me that my code is "too complicated," or "too strange."
Yeah, it's strange. Learn to live with it...
At work I've been added a 2nd technical contact and security contact for several projects because "you're less likely to be hit again". I think, but I'm not 100% sure, that is being done in a joking manner.
“We will be traveling via bus to a Dave & Busters nearby”.
“Those of you who meet expectations will board the bus at 8AM to go have fun, thank you for your contributions to the company in this past period”.
Ominously unstated is what happens to those who didn’t meet expectations.
Basically, decentralization. There can still be the Dev X who knows it all but everyone else should be able to maintain and evolve various pieces of the system should the need arise.
I spent plenty of time making sure there is enough documentation and attempting to get feedback on it, the project roadmap, milestones/schedule etc with a team that had almost zero engagement. Once I left, they weren't able to put things together despite a clear todo list of rewiring services to finish the project. it doesn't matter what architecture, amount of documentation, testing, how clean the code is etc, if your team is not engaged and doesn't share the same vision of where the project should go, the project is doomed to fail once you leave.
Responsibility for various sub-systems is already distributed to many individuals. As for overall responsibility to maintain the canonical tree and merge patches in, it'll probably similar to the last time Linus stepped down for personal reasons. Greg Kroah-Hartman handled the 4.19 release of Linux while Linus took a break.
If you care a lot about a specific project and want to prepare then it's similar to preparing for any other disaster.
* Documentation and written processes for everything. People like to feel irreplaceable, but it's far more valuable to make yourself unnecessary. In high stress situations, people make bad decisions, so having well-oiled play books is important. E.g. see [0].
* Practice and simulations: at large companies people are sometimes put on surprised forced vacation and are not allowed to communicate with their team.
* Foster a culture of encouraging people to step out of their box - if Important People's decisions can be questioned, then the rest of the team will better understand them and will be able to cope better with making them if necessary
[0] https://www.atlasobscura.com/articles/pointing-and-calling-j...
There are upsides and downsides to this. Foster a culture of 'document everything', and you'll quickly end up with a corporation which runs like molasses as everyone has to spend time writing up meeting minutes and spends 90% of their time updating documentation and arguing over if something is allowed within the XYZ procedure.
In my orgs, I generally say "a 1 pager quickstart guide on how each subsystem works, and everything else is docstrings and comments in the code".
If the system is too complex for that to be enough for a new engineer to understand whats going on, then your system should be redesigned to be simpler. We're designing apps and web services. If it's complicated, then you're doing it wrong.
You still need to do something even if you know this. Replacing the system is not an option, since the next one will be just as bad.
* evolving requirements over time (a rewrite fixes this)
* A tech lead overcomplicating things for job security or to justify expanding the team or a promotion. This is rarely easy to fix, because typically now things will depend on crazy complex semantics... "We extended our pubsub system into a probabilistically lossy data caching layer!" I normally fix it by moving the project to 'maintenance mode' and reducing headcount to 0.5 or so. Obviously it's best to have enough oversight that that kind of thing doesn't happen in the first place.
Apparently not the walrus.
Any good refs or documentation available on what governance the foundation was given at the time he stepped down?
But for software engineering in general, you want a culture of people focused on working as a team towards the mission, not on individual metrics/career. This affects what you do, how you to it, how you document it, how you make decisions, etc. If there's no immediate plan for what to do when the lead dev not available, they'll figure it out.
(And if SHTF before you fix culture or move, then the question of succession for a lead dev can just be bumped up the management hierarchy at that time. And the interim solution can be creative based on the details of the immediate situation. For example, there might be an obvious successor, based on their background, skills, and availability at that moment, and the nature of that might determine whether to be thinking of them as interim, provisional, or long-term.)
They're still up and running and doing really well.
Edit: So it doesn't seem like this is because I documented everything well and code was good. That wasn't the case. They just managed.
Ask a small dev team "what would happen if the main technical person left suddenly?", and they'll normally tell you the companies product would collapse.
But when that happens, the usual outcome of a key person leaving a small team is usually that the teams productivity is reduced for a few months while someone new is found and fills the space.
As a Lead:
When my wife had heart problems, I instantly told my team to go on auto-pilot, who would run their ceremonies, and went to support my wife. When I got called by someone with a question that was answerable by my team, I chewed them out. This is all with 100% support from my director.
As a developer:
I'm working on a product where the product has been developed by one dev largely for many years. I'm at the 6 month mark now, and honestly, if I had to step up to support everything myself, it'd suck, but the company would keep going. Would I have to change how a few things work? Probably. But would we get our releases out: Absolutely. Usually at 6 months, I could take over most products but this one is very specialized. (Which is why I joined up. I knew the ramp was longer, and I had more growth. :) )
And that is the real story: If you want to get that "truck number" up. Get someone else into your codebase, and working. If not expect some lag while they come on-line, but that the world will keep spinning.
... Also look for people who can learn, over just raw skills in a replacement scenario. Clearly they need to know enough, but it may take you longer to find someone who can check every box, than get someone and have them ramp up to "good enough" quickly, missing a piece or two. Heck you might want 2-3 developers.. something about learning your lesson.
Yikes. A trivial work issue is something someone might use an excuse to check on you and make sure your wife is okay and that you're alright.
Hi X. Hope things are going ok. Tell us if we can do anything.
Alter for cultural differences, closeness of relationship, situations where things are not going to be ok.
Understanding the above article is very important. Instinctively, we want to help. But figuring out how to, without "dumping in" is critical.
If you are worried about a person in the situation like the one I was in, figure out the right way to help them. If they say don't call. Honor that.
As for "chewing out" my wording was strong there for what I did. Though I'd support someone chewing out someone there. I pointed out that my team could make choice X without me, and that I'd left clear directions on who could do what. I referred them back to that person, and reaffirmed my teams choices, which either good enough or the exact choices I would have made.
Yes, the person was doing what you suggested. But that's not a good thing to do. If they want to help me, not interrupting me is important,
I'd also left my personal e-mail... so an e-mail was much more appropriate, and would have been received better. Also it gives me time and space to think. Which are precious in moments like that. I may not know how you can help me today.... but I may tomorrow.