In a traditional sense, the retention of developers for extended periods has been equated with success. But one problem is this perspective overlooks the potential negative consequences of prolonged exposure to the same codebase. Over time, programmers may develop a sense of entrenched ownership over specific sections of code.
It often results in a culture where one or a few individuals become the sole experts on certain parts of the codebase. This can lead to a complete reliance on these individuals for troubleshooting and decision-making, which hinders collaborative work and impedes overall team agility, and forces everyone to depend on these people for project success, even if they are underperforming. And if they suddenly quit, the project is destined to fail.
Solution
Preserving knowledge is paramount, and the most effective way to achieve this is through documentation and team rotation (no not firing people).
By documenting critical decisions, including the thought process behind them, we eliminate the need to repeatedly explain past discussions and choices. This ensures that even team members who join the project later understand why things are set up the way they are. Also team members should be rotated across codebases, not as a punitive measure, but as a strategic necessity for maintaining the health of the codebase, so one can mitigate the risks associated with entrenched code ownership, where no individual holds more information than others, since long-term team members may overlook the need to document certain aspects of the project, assuming that information is common knowledge, when it's not. Some may even exploit this situation to their advantage, using their accumulated knowledge as leverage.
Knowledge should be dispersed throughout the entire project rather than being concentrated in the hands of a select few.
The project should be self-explanatory. When introducing a new decent developer to the codebase, they should require NO clarification from others. They can simply read the code and relevant documents, easily setup the project and immediately begin making significant contributions. Detailed documentation is necessary for facilitating smooth onboarding, to provide newcomers with the necessary insights in order to navigate the codebase independently. It should include technical specifications, design rationale, coding conventions, and best practices – essentially, every decision made in the project from the ground up.
If you have code silos, it indicates a lack of quality in the project code. In that case, an independent code audit won't hurt from time to time.