Notifications
Clear all
Topic starter
20/08/2026 5:50 pm
TL;DR: Seven recurring signals mark a codebase as unmanageable, including rising cyclomatic complexity, duplication, coupling, bug density, security debt, and developer turnover, according to Sonar’s analysis. The practical lesson is that code health stops being a subjective debate once teams measure maintainability, reliability, and change risk in the same operational view.
NHIMG editorial — based on content published by Sonar: Seven indicators of an unmanageable codebase and why they matter
By the numbers:
- Developers can spend as much as 84% of their time on maintenance and remediation rather than new feature work.
- 50%, anaged code quality can slow service delivery by up to 50%, turning technical debt into a direct velocity tax.
Questions worth separating out
Q: How should engineering teams measure whether a codebase is becoming unmanageable?
A: Track complexity, duplication, coupling, bug density, and test coverage at module level, then watch whether those signals are worsening in the same areas.
Q: Why do high-complexity systems create more delivery and security risk?
A: High complexity increases the number of paths developers must reason about, which makes testing harder and regressions more likely.
Q: What do teams get wrong about code duplication and coupling?
A: They often treat them as maintainability issues only, when they also create change-risk and consistency problems.
Practitioner guidance
- Measure the code health signals that predict failure Track cyclomatic complexity, duplication, coupling, defect density, and test coverage at module level so teams can see which areas are becoming unmanageable before delivery slows.
- Set quality gates on new code only Prevent existing debt from growing by enforcing automated merge checks on newly changed code, while separately scheduling remediation for the worst legacy modules.
- Prioritise the highest-risk modules first Use reliability ratings and issue severity to rank the code paths most likely to drive bugs, change failures, or security exposure, then refactor those first.
What's in the full article
Sonar's full article covers the operational detail this post intentionally leaves for the source:
- Module-level metric descriptions for reliability, maintainability, security, duplication, and cyclomatic complexity
- Examples of how SonarQube quality gates enforce pass-fail standards during SDLC workflows
- The relationship between code health findings and DORA metrics such as MTTR, CFR, and lead time
- Guidance on how SonarQube surfaces the specific modules that are driving codebase unmanageability
👉 Read Sonar's analysis of the seven indicators of an unmanageable codebase →
Unmanageable codebases: what engineering leaders should measure now?
Explore further
20/08/2026 6:30 pm
Code manageability is a governance problem before it is an engineering problem. Once complexity, duplication, and coupling prevent teams from understanding what will break, the codebase has crossed from technical debt into operational risk. That matters because the same pattern appears in identity programmes when access rules, lifecycle steps, and ownership records become too fragmented to govern with confidence. Practitioners should treat manageability as a control objective, not a cleanup exercise.
A question worth separating out:
Q: How should teams respond when debt and turnover are both rising?
A: Prioritise knowledge capture, documentation, and test coverage before more engineers leave, because turnover turns understood debt into opaque debt. Then focus remediation on the modules most likely to fail during change. The goal is to keep the organisation able to reason about the code after the original authors are gone.
👉 Read our full editorial: Seven indicators of an unmanageable codebase and why they matter
