I recognize this is an extract from a larger book I haven't read, but my main reaction is: prove it.<p>All of this reads to me like a software developer complaining at the pub.<p>The wording is strong and the premise that "employee churn is <i>lethal</i> to software companies" is an extreme claim. Yet, not one company is used an example of one that died due to employee churn.<p>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)
> The death of a program happens when the programmer team possessing its theory is dissolved.<p>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.<p>But I think this only one side of the story, and probably its the side we have least influence over.<p>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.<p>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.<p>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.
I like the idea, but I feel like in the context of an enterprise there can be other non-coder roles to help maintain a mental model for future “generations”. As a Technical Product Manager I don’t help with coding often, but usually will create onboarding documentation centered around the “theory” of the system’s programming to help cut down on churn if we bring in new resources.
Missing from the complaint is “too much” churn. But then it’s boring and obvious. Too much employee churn is lethal to any company.<p>Not a huge insight.<p>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.
I think this is true, at least the underlying concept.<p>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.<p>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.
One of the things I find myself needing to push both junior _and_ senior developers to do is "if you are thinking about code being anywhere adjacent to 'subtle' or 'weird,' or think that something might become a design pattern for future code, or something that was copied from other code but differs subtly, or you consulted StackOverflow... write the comment that's in your head/leave a breadcrumb as an actual comment in the codebase." And, frankly, this sometimes means commenting-out rather than deleting code, if the historical code was necessary to understand the context for why the improvement is warranted.<p>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.<p>One of my favorite books, Vernor Vinge's Hugo-winning _A Deepness in the Sky_, uses the term "programmer-archaeologist" - <a href="https://akkartik.name/post/deepness" rel="nofollow">https://akkartik.name/post/deepness</a> is a great (spoiler-free) quote on the notion. Writing <i>for</i> your future archaeologists - who may very well happen to be your future self! - is a great mental model to have.<p>(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.)