Ma réaction à un commentaire (je ne l'ai pas publié).

@SirBenJamin_ 1 hour ago
In my experience, most coupling problems (and other architecture problems) are caused by teams where everyone works on all parts of the codebase, i.e people don't specialise in a particular area, they just pick up the next ticket on the backlog, and then even worse, other people who also have no experience in the area review the code. Managers will see this as a good thing, as they think they're getting more bang for their buck by 'spreading the knowledge.' ... but I really don't think it ever ends up like that, and the codebase suffers

I think "everyone works on all parts of the codebase" could not be a problem per se if the knowledge is evenly distributed. In very big systems it might not be possible and thus I agree with you that specialization could be an useful strategy. Also, you back this with your experience, so empirical evidence strenghtens your point.

In systems not so big, I think that T shape profile along with good ownership distribution (with pair programming, ensemble programming, ADRs), could also have positive effects on coupling problems. Meaning having knowledge a bit larger than hers scope could help having a glance of neigbourg culture (such as how mapping is done in the team next to me).

Techniques such as "swarming" : helping others being stuck or learning things outside of our initial scope (ex. QA, learning a bit of programming skill, Backend learning a bit of frontend ...) might help growing more shared mental models and thus slowly growing in the direction of full stack profile.

This lovely comic illustrates it pretty well I think : https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000