Divergent Change: What It Costs and How to Fix It
A single class that must be modified for many different, unrelated reasons.
What It Is
Divergent Change is the opposite of Shotgun Surgery. Instead of one change requiring edits in many classes, Divergent Change means a single class is modified for many unrelated reasons. If you change the class when a database schema changes, when a UI requirement changes, and when a business rule changes, you have Divergent Change. The class has accumulated responsibilities from multiple domains, making it a bottleneck that every change must flow through.
Why It Costs Money
The class becomes a merge conflict hotspot. When unrelated changes (database, UI, business logic) all modify the same file, developers working on independent features collide. The merge conflict rate scales with the number of change reasons multiplied by team size.
Testing is expensive because each change reason has different test requirements. Database changes need integration tests, UI changes need rendering tests, business logic needs unit tests, and they all live in the same class.
Code review quality drops. Reviewers cannot specialise: a database expert reviewing a PR that also contains UI changes in the same file must review code outside their expertise or approve blindly.
Specific Cost Mechanisms
- ●Merge conflicts: 1-3 hours per conflict, occurring multiple times per sprint
- ●Cross-domain testing: each change requires running all test categories for the class
- ●Review quality: mixed-concern PRs take 2x longer to review and catch fewer bugs
Estimated Annual Cost
Cost per instance by team size and codebase size. Based on $120,000 average developer salary. See full methodology.
| Team Size | Small (<50k LOC) | Medium (50k-200k) | Large (200k+) |
|---|---|---|---|
| 3 devs | $4,000 | $9,600 | $19,200 |
| 5 devs | $6,600 | $16,000 | $32,000 |
| 10 devs | $10,000 | $24,000 | $32,000 |
| 20 devs | $13,200 | $32,000 | $32,000 |
How to Detect It
Specific rules and thresholds for automated detection. See full tool comparison.
High class coupling and many responsibilities
Large files that change frequently across commits
Files with highest commit frequency across different feature branches
Identifies files changed by many different authors for different reasons
Refactoring Patterns
Proven techniques to eliminate this smell. See all refactoring patterns.
Extract Class
Groups of methods that serve distinct change reasons
Extract Module/Package
The extracted classes form a coherent domain boundary
Apply Single Responsibility Principle
The class has 3+ identifiable change reasons