Maintenance (and maintainability) are definitely key questions for software development.
The first point, about keeping people who write maintainable code, I agree with 100%.
The second one, about keeping codebase expertise, seems complicated.
On one hand, we all know there are weird bugs and edge cases best handled by knowing the code intimately. What's 20 hours of QA and engineering for an unfamiliar team can be a 5 minute tweak for the guy who wrote the method, even with clear code and good tests. Weird bugs do happen, and just knowing that what it isn't can help with finding some awful probabilistic issue.
On the other hand, I wonder if this is a "controlled burn" kind of issue. Everyone's heard of systems that work fine for 20 years and then explode as soon as the expert leaves. Normally that's a design and maintainability issue, but at some level we're talking about bus factor here. You're definitely trading fewer crises for worse crises, but I don't know the rate on the tradeoff.
Obviously unplanned turnover is still a huge issue, but I do wonder what the right balance is on "just knows how to fix it" versus "institutional knowledge is safer than personal".
It's possible to write bug or enhancement requests against the system if it takes too long for new contributors to come up to speed. I do this from time to time.
It's important to remember that specify specific exit criteria, like "it should take one command instead of fifteen to add a new request to the XYZ endpoint."
The first point, about keeping people who write maintainable code, I agree with 100%.
The second one, about keeping codebase expertise, seems complicated.
On one hand, we all know there are weird bugs and edge cases best handled by knowing the code intimately. What's 20 hours of QA and engineering for an unfamiliar team can be a 5 minute tweak for the guy who wrote the method, even with clear code and good tests. Weird bugs do happen, and just knowing that what it isn't can help with finding some awful probabilistic issue.
On the other hand, I wonder if this is a "controlled burn" kind of issue. Everyone's heard of systems that work fine for 20 years and then explode as soon as the expert leaves. Normally that's a design and maintainability issue, but at some level we're talking about bus factor here. You're definitely trading fewer crises for worse crises, but I don't know the rate on the tradeoff.
Obviously unplanned turnover is still a huge issue, but I do wonder what the right balance is on "just knows how to fix it" versus "institutional knowledge is safer than personal".