That doesn't look like a problem with replicated and rewritten code; that seems a symptom. If you don't have somebody "watching the kids" (and with the clear a

That doesn't look like a problem with replicated and rewritten code; that seems a symptom. If you don't have somebody "watching the kids" (and with the clear authority and technical abilities to "go all Moe on the other Stooges", when that's needed), kids will have a habit of replicating software. Always have. Kids do tend to get themselves in trouble. That's why you have to watch them. The kids will tend to skimp on documentation and testing and integration, and on refactoring before release, and on consistent APIs and nomenclatures and formatting and development practices. You can sometimes spot these projects from afar, too; the projects that shipped, and didn't get cancelled. Look for inconsistent or confusing UIs, or poor documentation. For frequent patches, repeated patches, or regressions. Edge cases. A lack of integrated debugging. Problematic upgrades. All can be areas that tend to be short-changed. Being the "Moe" guy in a project tends to be political; if you're doing it right, you're probably everybody's target. You're balancing what the engineers and the testers and the managers and the customers and the schedule and budget and the egos will permit, and each group is going to be unhappy about something.