I can see the siloed approach working to a point, but there are two big drawbacks:
- no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward.
- no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it.
Essentially, having all your team hived off from each other, doing their own thing:
- gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge.
- reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong).
If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.
- no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward.
- no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it.
Essentially, having all your team hived off from each other, doing their own thing:
- gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge.
- reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong).
If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.