This is one of my favorite principles, don't try to make the codebase "too DRY" . I often see it cause stress and complexity in platform or infra teams trying t

This is one of my favorite principles, don't try to make the codebase "too DRY" . I often see it cause stress and complexity in platform or infra teams trying to support large communities of developers. It's right to be concerned that a bunch of teams might be a wasting time implementing the same thing slightly differently, or that you'll end up fixing the same bug across all these "copies". Often that kind of duplication is good for the business though, and the platform team doesn't have the insight to see all the divergent requirements on the horizon. Letting the teams innovate separately without having to coordinate changes in all these DRY-ied up systems can be the best way to support them. Or even more abstractly, zero codebase chaos is not the optimal amount.