Employee Turnover is good for Code Maintainability
There’s a strong focus on technical aspects about software development: tools, libraries, frameworks, performance, deployment, etc.
Maintainability is slowly gaining attention thanks to experienced people that understands how important is that.
But there’s one thing that in my opinion is really neglected: the developers.
Writing software is a creativity process made by human beings, and the way you put the developers in front of the code has great influence on your codebase. Other than the almost obvious concern about “how my developers works together?” there’s the “how they feel to the code?”.
If they are passionate developers (and your team is only made of enthusiasts and passionate developers, right?), the true is, they have feelings for the code: software is their creature, they love the newborn, they’re proud when the code works and does more things, they’re disappointed when the code is full of bugs or in a bad unmaintainable shape, probably ruined by others developers that didn’t understand how to manage it!
Moreover, if you consider that “developers volant, code manent” (and you have to maintain or rewrite it) this is a key aspect in the long term, and you see that probably feeling a strong code ownership is not a good thing.
As a consultant, I’m usually in the role of “volant” developer, where is even more important to promote a “collective code ownership”, but it’s a decisive choice that have to be made by the employer. So when I recently ended up on this article that elaborates on the subject, I couldn’t disagree with that: