If you lose all knowledge of one of your systems, you need to rediscover what you already learned. This is extremely debilitating. But even if you don't lose all knowledge, as Brooks Law states
> It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
The more churn that you have, the slower you can move. If you are Edison and have not yet created the light-bulb, but you have tried 1500 different attempts, and you were tasked with training a replacement, do you really think you would walk through all 1500 of those experiments? To be able to move forward, you not only need to know the happy path(what ends up in the code-base), but what doesn't, and why. That almost never makes it to the new hire. They will make that mistake again.
> It takes some time for the people added to a project to become productive. Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
The more churn that you have, the slower you can move. If you are Edison and have not yet created the light-bulb, but you have tried 1500 different attempts, and you were tasked with training a replacement, do you really think you would walk through all 1500 of those experiments? To be able to move forward, you not only need to know the happy path(what ends up in the code-base), but what doesn't, and why. That almost never makes it to the new hire. They will make that mistake again.