Seven indicators of an unmanageable codebase and why they matter

At a glance

What this is: This analysis shows how code manageability can be measured through complexity, duplication, coupling, defect patterns, and security debt, with SonarQube used to turn code health into objective signals.

Why it matters: It matters to IAM practitioners because the same governance problem appears in identity programmes when unmanaged complexity, stale ownership, and weak review processes create hidden risk across service accounts, secrets, and access workflows.

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.

👉 Read Sonar's analysis of the seven indicators of an unmanageable codebase

Context

Code manageability is the point at which software remains understandable, changeable, and testable without constant rework. Once complexity, duplication, and coupling rise together, teams stop managing code and start absorbing hidden operational risk, including security flaws and delivery drag.

For identity and access programmes, the same pattern shows up when lifecycle controls, ownership, and policy enforcement become too fragmented to govern consistently. Hidden complexity in code often mirrors hidden complexity in access systems, where unmanaged dependencies create the conditions for drift, stale credentials, and brittle approvals.

Key questions

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. A codebase becomes unmanageable when changes create more rework, more defects, and more uncertainty than the team can absorb safely. Measurement should drive prioritisation, not just reporting.

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. It also obscures validation logic, error handling, and edge cases, which can create security gaps. The practical risk is not complexity alone, but the loss of confidence in whether a change is safe.

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. Duplication means one fix must be repeated, and tight coupling means one change can trigger many others. That combination raises the chance of inconsistent updates, hidden defects, and unstable releases.

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.

Technical breakdown

Cyclomatic complexity and cognitive complexity in practice

Cyclomatic complexity counts the number of independent paths through a function, while cognitive complexity measures how hard that code is to understand. The two are related but not identical: code can be logically simple yet hard to follow, or structurally branched and costly to test. When these measures rise, bug fixes take longer, code review quality drops, and test coverage becomes less reliable. In governance terms, complexity is not just a maintenance issue, it is a control issue because teams lose the ability to reason about change safely.

Practical implication: set thresholds for complex functions and block new complexity from entering critical paths.

Duplication, coupling, and ripple change risk

Code duplication means the same logic is repeated across multiple locations, so one fix must be applied everywhere. High coupling means components depend on each other so tightly that a local change produces downstream edits and inconsistent behaviour. Together, they create ripple effects that raise change failure rate and make refactoring more expensive. This is the software equivalent of overlinked governance processes, where one adjustment in a control surface forces unplanned updates across the rest of the system.

Practical implication: identify duplicated logic and dependency hotspots before they become change-risk clusters.

Security debt, bug density, and untouchable code

Security debt appears when code quality issues and self-admitted technical debt point to weak validation, insecure design, or deferred remediation. Bug density shows where defects accumulate, but the more serious sign is when fixes create new faults in the same areas. Those modules become untouchable because the team no longer trusts its own change process. That is where operational risk hardens into governance failure, because no one can confidently attest to the security posture of the code in question.

Practical implication: treat high-defect modules as risk zones and require stronger review, testing, and ownership.

NHI Mgmt Group analysis

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.

Velocity tax is the hidden cost of unmanaged complexity. When teams spend most of their time maintaining brittle systems, delivery slows and security work competes with firefighting. The article’s core claim is not that bad code is inconvenient, but that it consumes the capacity needed to repair itself. Practitioners should connect code health metrics to release performance and risk reporting.

Security debt accumulates fastest where change is least observable. Self-admitted debt, low test coverage, and fragile modules create blind spots that attackers and defects can exploit alike. In identity-heavy environments, this is analogous to long-lived credentials and undocumented access paths that survive because no one owns the cleanup. Practitioners should align remediation priorities to the modules most likely to hide future failure.

Named concept: opaque debt. This article shows how understood technical debt becomes opaque debt when experienced developers leave and the code’s rationale disappears. The result is higher remediation cost, lower confidence, and weaker security validation. Practitioners should preserve knowledge, documentation, and test coverage before turnover turns manageable debt into a structural liability.

Quantitative code health is the only credible basis for refactoring decisions. Subjective complaints rarely justify investment, but measurable complexity, defect density, and coupling do. That is why continuous analysis is more useful than periodic opinion. Practitioners should use objective code health data to decide where refactoring reduces the most risk per unit of effort.

What this signals

Opaque debt is the same governance failure identity teams face when ownership disappears. As code becomes harder to understand, organisations lose the ability to prove what changed, who approved it, and whether the change is safe. That maps directly to lifecycle drift in identity programmes, where undocumented service accounts and stale entitlements create similar blind spots.

Engineering leaders should expect code health metrics to become part of broader resilience reporting, not just developer tooling. Where complexity and defect density are rising together, delivery risk, operational risk, and security risk are already converging.

Teams that already use identity governance disciplines can apply the same logic here: define ownership, measure drift, and remove ambiguity before it becomes outage or breach material. For related identity patterns, the Top 10 NHI Issues and Guide to the Secret Sprawl Challenge show how unmanaged sprawl becomes harder to unwind once it scales.

For practitioners

• 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.
• Preserve knowledge before turnover increases debt Document critical modules, improve test coverage, and rotate reviewers so the team does not lose code rationale when experienced developers leave.

Key takeaways

• Unmanageable code is measurable, and the key signals are complexity, duplication, coupling, defects, and security debt.
• The business cost is not abstract, because poor code health translates into maintenance drag, slower delivery, and higher risk.
• The fastest path to control is continuous measurement, prioritised refactoring, and stronger ownership of the code that changes the most.

Key terms

• Cyclomatic Complexity: A measure of how many independent paths exist through a function or module. Higher complexity usually means more branching, more testing effort, and greater risk that a small change will create unexpected behaviour or maintenance overhead.
• Cognitive Complexity: A metric that estimates how hard a function or code path is to understand, based on nesting, branching, and flow changes. Higher scores usually mean more mental effort for reviewers and a greater chance of maintenance errors.
• Technical debt: Legacy shortcuts or weak design choices that create future cost, risk, or operational friction. In identity programmes, technical debt often shows up as brittle trust relationships, inconsistent revocation, poor traceability, or controls that only work in one environment and fail in another.
• Quality Gate: An automated release control that blocks code when it fails security, test coverage, or maintainability thresholds. It converts review criteria into deterministic enforcement, which is especially important when code is produced by AI systems that may not self-detect environmental or adversarial weaknesses.

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

👉 Sonar's full article explains the metrics, quality gates, and remediation logic in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management through a practitioner lens. It is suitable for security teams that need a common governance model for identities, access, and lifecycle controls.