What is the difference between checking only new code and trying to fix the entire codebase at once?

Checking only new code means teams apply standards to what is being added or changed now, while leaving legacy defects to be improved gradually. Trying to fix everything at once often creates delay, cost, and resistance. The incremental model is easier to operationalize, keeps delivery flowing, and raises quality without forcing a large-scale rewrite.

Why Incremental Standards Beat a Whole-Codebase Rewrite

Checking only new code is a policy choice about scope: each change must meet today’s standard, while existing legacy debt is handled over time. That makes the control easier to run consistently because teams review what is being introduced now, not every old defect at once. The approach also avoids turning quality improvement into a blocking modernization programme.

In practice, this difference matters because code health is usually limited by throughput, not by the abstract desire to make everything clean. New-code checking creates a repeatable gate for future risk, while the backlog of older issues can be reduced through targeted refactoring, prioritisation, or opportunistic remediation. The result is a steadier quality curve instead of a one-time disruption.

Trying to fix the entire codebase at once sounds thorough, but it often changes the problem from quality control into programme management. Large remediation efforts depend on wide coordination, deeper testing, and more tolerance for delivery slowdown. When the effort is too broad, teams may delay releases, defer adoption, or work around the standard rather than absorb the cost of immediate full compliance.

Where the Incremental Model Fits Best

Incremental checking is strongest when a codebase is already large, the team needs to keep shipping, and the organisation wants measurable improvement without freezing change. It works well when standards are enforced at the point of introduction, because that prevents the risk surface from growing further while still leaving room to improve older areas in sequence.

The approach also supports clearer ownership. New code can be assessed against current rules, while legacy remediation can be assigned as a separate stream with its own priorities and deadlines. That separation helps teams avoid confusing prevention with cleanup, which are related but operationally different tasks.

By contrast, a whole-codebase attempt is most plausible only when the legacy estate is small, the defect class is severe, or there is a compelling change window that justifies the disruption. Outside those conditions, the all-at-once model tends to create more friction than value, especially when the organisation needs continuous delivery.

How to Decide Between the Two

The practical question is not whether legacy defects matter, but whether they must be fixed before the organisation can safely keep moving. If the answer is no, then new-code enforcement gives you immediate control over future quality without waiting for a perfect baseline. If the answer is yes, then the remediation effort should be treated as a focused programme with explicit scope, deadlines, and acceptance criteria.

Teams often underestimate the difference between policy clarity and remediation capacity. A rule that applies to new code is easy to explain, automate, and audit. A rule that demands instant correction across the whole estate requires inventory, prioritisation, regression testing, and sustained engineering attention, which can be disproportionate unless the risk is already acute.

The best operating model is usually hybrid: prevent new defects first, then burn down legacy issues in measured waves. That keeps the standard moving forward while reducing the chance that improvement work itself becomes the main source of delay.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP SAMM, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP SAMM	Software Assurance Maturity Model	The question is about incremental quality enforcement in software delivery.
Recommendation — Use SAMM to phase security and quality improvements into the delivery lifecycle.
CIS Controls v8	CIS-16 — Application Software Security	Incremental checks on new code align with secure development and release controls.
Recommendation — Apply CIS-16 to gate new code with secure development and review practices.
OWASP ASVS	V15 — Secure Coding and Architecture	The topic concerns how standards are applied to code changes and codebase quality.
Recommendation — Use V15 to define what new code must satisfy before it is merged.
NIST CSF 2.0	PR.IP-02 — Actions to protect information systems and assets are managed	Incremental remediation is a managed protection activity rather than a one-time rewrite.
Recommendation — Manage remediation as an ongoing protective process with clear ownership and cadence.

Practitioner Guidance

What to prioritise: Enforce the standard on new or changed code first, because that is the smallest control boundary that can be applied reliably without halting delivery.

What to verify: Confirm that legacy remediation has an owner, a backlog, and a sequencing rule, so “we will fix it later” does not become permanent exception handling.

Common mistake: Treating a full rewrite or full remediation as a quality strategy when it is really a delivery-risk decision that needs separate business approval.

Practitioner takeaway: New-code enforcement is usually the sustainable control, while whole-codebase cleanup should be reserved for cases where the legacy risk is severe enough to justify a deliberate slowdown.