Maintenance grows because larger organisations usually have more dependencies, more integration points, and more coordination overhead. As codebases expand, small changes create more regression risk, more testing, and more security follow-up. The article also suggests that teams with many developers spend more time in meetings and operational tasks, which further compresses the time available for writing and improving code.
Why maintenance scales badly in larger codebases
Maintenance slows down because larger organisations inherit more coupling, more dependencies, and more paths where a small change can break something unexpected. The work is no longer just editing code, it becomes coordinating impact across teams, environments, reviews, tests, release windows, and security checks. That overhead grows faster than the code change itself.
One practical reason is that the cost of change includes discovery. In a bigger system, developers spend time figuring out who owns a component, which interfaces are stable, what assumptions other services make, and whether the change will ripple into production incidents or compliance work.
The same pattern appears in NIST Cybersecurity Framework 2.0 style governance work, where coordination and control verification add effort around change, even when the underlying code edit is small. In practice, maintenance becomes a systems problem, not a typing problem.
Why teams spend more time on testing, review, and rework
As organisations grow, changes usually require more regression testing because the blast radius is harder to predict. A developer who can safely change one function in a small product may need multiple test passes in a larger estate, because shared libraries, legacy services, feature flags, and deployment pipelines all create hidden dependencies.
That extra effort is not just technical overhead. Review cycles lengthen when more people must approve the design, validate the business impact, or confirm that a change fits platform, security, and release standards. The result is more waiting, more clarification, and more rework before a change is considered safe.
This is also why generic implementation guidance from the OWASP Cheat Sheet Series remains useful: maintenance gets slower when teams must repeatedly re-verify security-sensitive behaviours after every change, especially around authentication, session handling, and secrets management.
Where the estate includes shared credentials, tokens, or machine-to-machine access, maintenance often becomes OWASP Non-Human Identity Top 10 work as well, because routine code updates can force secret rotation, privilege review, or dependency checks across systems that many developers never directly see.
Why meetings and operational work crowd out coding time
In large organisations, developers rarely work in isolation. They coordinate across product, security, infrastructure, QA, and operations, so even a modest change can trigger discussions about scope, risk, rollout timing, ownership, and incident readiness. The more interconnected the organisation, the more time goes into alignment before code is written.
Operational burden also rises because larger teams usually support more environments, more handoffs, and more production dependencies. That means more time spent on triage, ticketing, deployment support, and post-release follow-up. Over time, the developer role shifts from primarily building features to managing the organisational machinery around the software.
For teams that maintain many integrations or APIs, this overhead is amplified by authorisation checks, interface compatibility, and version management. A change that looks local in code can still require wide operational coordination because the consuming systems are spread across departments or product lines.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Oversight of cyber risk | Code maintenance overhead reflects governance and oversight burden across changes. |
| PR.IR-01 — Networks and environments are recovered from cyber incident conditions | Larger codebases create more rework and recovery effort after changes fail. | |
| Recommendation — Streamline change oversight so routine maintenance is not slowed by unnecessary review layers. Design change pathways so failed maintenance can be rolled back quickly and safely. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Maintenance in large systems often includes secret rotation and lifecycle cleanup. |
| Recommendation — Replace long-lived secrets with shorter-lived credentials to reduce maintenance burden. | ||
Practitioner Guidance
What to prioritise: If maintenance time is rising, look first at dependency count, shared ownership, and release friction. Those three factors usually explain more delay than raw code volume.
What to verify: Check whether developers are spending more time on coordination than implementation. If meetings, approvals, and post-change remediation dominate the calendar, the organisation is paying a structural cost for complexity rather than a tooling problem.
Decision rule: When a small change consistently requires many reviews or test cycles, treat that as a signal to simplify interfaces, reduce coupling, or split ownership boundaries before trying to optimise individual developer effort.
Practitioner takeaway: Maintenance becomes expensive at scale when the organisation treats every code change as a cross-system event, so the real lever is reducing coordination and dependency load, not asking developers to move faster.
