All of this reads to me like a software developer complaining at the pub.
The wording is strong and the premise that "employee churn is lethal to software companies" is an extreme claim. Yet, not one company is used an example of one that died due to employee churn.
In short, I don't buy it. There's generally only a tenuous relationship between software quality and business success to begin with, and history has shown over and over that the importance of software quality is far more important at the beginning of a business (or product) than after it's established. So to claim that employee churn kills entire companies needs a lot to back that up, starting with numbers (which there are none in here)
I think that from the business folks' perspective, you might say they're no longer playing to win, they're just playing to not lose. Which, in many portions of the tech space, is a recipe for inexorable decline.
Howrver, if you read the related programming as theory building it explains these thoughts in greater detail.
It explains a lot about how code becomes legacy and the friction that comes in from inheriting a 0 handoff software project.
I think that cuts both ways though, because I think even the business people would be shocked at how well things can seem to work despite serious dysfunction. If an entire team dies off but 3 months later things seem "fine," the business types will just assume everything is as good as it ever was. I know it's popular these days to say that good tech and good business are not always the same thing, but I do think that many of those same businesses would be a little worried if you actually convinced them that their tech was coming off the rails and was only going to get worse. Some businesses just want to be acquired and don't care what happens after that, but not every business thinks they're on a clock.
If you're big enough, like say you're a trillion dollar megacorp, then important teams folding up and being reborn is just part of your ecosystem. I've seen big tech power through churn for years with nothing but human wave tactics until the business climate changed enough that the team in question became less critical, and that's when they let it die.
https://news.ycombinator.com/item?id=34328069 - Jan 2023 (420 comments)
I really like this quote. And if we look at what is generally called "legacy software" it mostly fits pretty well with this description. And I agree with the idea that to have a proper living program you need people with experience in this specific domain, consequently if you have too much churn in your team your programs can die.
But I think this only one side of the story, and probably its the side we have least influence over.
Another component for this problem is how easy is to understand a program. Imagine your program is distributed and you need a consensus algorithm. In a broad sense both Paxos and Raft are good solutions for your problem. But by choosing Paxos you are making things harder for anyone who needs to join this team in the future.
And this is just due the fact that people generally have a hard time understanding how Paxos work. Sure, there are several techniques one could use to limit the impact of choosing Paxos can have over a program. Its not that hard to isolate networking behind an interface and treat Paxos as an "implementation detail". But the reality is that predicting what things should be completely isolated is pretty hard, especially if your prediction needs to happen 5 years in advance. And when you don't properly isolate these things they spread all over your codebase.
This is why I think the metric "how easy is to explain this code?" is pretty important. If we want to create successful programs (which one way to measure would be "programs that outlive their original teams") we need to be mindful about how we structure our code. "Literate programming" is probably a good way to think about this, in the end of the day we are writing code for other humans to read and understand. If that wasn't important we could all be working with minified source files.
Not a huge insight.
But if we could somehow arrive at the answer to how much is too much, it’d be something that can be optimized for. And we’d live in a fascinatingly different world.
Yea the program in code does exist as a thing that will do exactly what it says in a deterministic (mostly? lol) fashion, since it's, you know, a computer.
But a team's ability to modify the code, to fix inevitable problems or add new features, depends on the mental model of the code that exists in their head(s). That's also why there's a massive increase in complexity of a project as soon as it gets too big to fit inside one person's head.
I wholeheartedly agree with the OP that "churn" can result not only from staff members leaving, but also from them shifting focus to other projects or even just growing in skillsets over time. Which is why it's vital to document the mindset you had as you were coding.
One of my favorite books, Vernor Vinge's Hugo-winning _A Deepness in the Sky_, uses the term "programmer-archaeologist" - https://akkartik.name/post/deepness is a great (spoiler-free) quote on the notion. Writing for your future archaeologists - who may very well happen to be your future self! - is a great mental model to have.
(And read Deepness - despite its branding as book 2 in a series, it's arguably best to read it standalone first! It's simultaneously an action-packed popcorn novel and a mind-bending set of discussions on linguistics and cultural relativism as they pertain to mechanisms for societal control, in a way that makes the reader part of that very conversation. Highly, highly recommend.)
