Earlier quoted context omitted.
> I had a manager at a startup tell me that conventional management assumes that engineers will only stay at a company for 18 months, so they really pile on the stress which is ironic, because isn’t that why people stay less and less longer at a company (can’t stand the slog)?
I think economically it may make sense to hire fresh people for less money, burn them out and then have them leave soon. This may be one reason for ageism .
Also, there is a great deal of emphasis placed on process. If you will have new people taking over the code all the time, you should have a fairly strict requirement for patterns like MVVM and VIPER, and require new hires to be able to adapt to these quickly.
The Japanese had a similar structure, because they rotate engineers around every couple of years. The engineers stay with the company forever, but they change jobs frequently.
That means that it's very important to have a strict policy of heavily-documented, inflexible process, and you can have vast legacy codebases that people are afraid to change. If you can farm a lot of that out to a dependency framework, then it becomes S.E.P. (Somebody Else's Problem).
I'm not a huge fan of this approach, but many companies seem to feel it works.
There was a company called Taligent that took this to extremes. I read their style guide (I spent a great deal of time researching how other people did development -it made me quite the cynic). They had the strictest, most convoluted structure I've ever encountered.
Taligent eventually collapsed under its own weight. The idea was to only have Architects be creative, making line programmers little more than data entry. Programmers couldn't do stuff like create new classes without getting permission from an Architect.