The sweet spot is for someone with deep experience to lay down the skeletal structure of the tests, rpc, infra, lifecycle, etc… then hand it off to a broader team who could learn the intention behind the decisions.
> who could learn the intention behind the decisions
If people did learn those intentions we wouldn't have the problems we have.
I inherited a project like this once as the third generation to take it over. The (evidently, I never met them) well trained and experienced first developers laid down a foundation using a textbook OO style with a few little tricks needed to make that work in a language where OOP support was bolted on. The code was not perfect, but it was professional work and I would put it around the 80th percentile in terms of code quality.
These tricks caused the virtues of that foundation to be overlooked entirely, and so the project was essentially reimplemented in spaghetti style over time with various ad hoc stovepipes to pass data back and forth between the two sides when the original had functionality that wasn't understood well enough to be reimplemented.
The importance of training, communication, and retention can not be overstated.
