Why Code Festers: Five Conditions

A defect does not persist by accident. Five structural conditions, all present simultaneously, create a fester environment. Remove any one and detection becomes possible.

Condition 1: Correct Output

A list and a set answer the membership question identically. list.contains(x) and set.contains(x) return the same boolean. A ThreadLocal carrying stale identity still carries an identity — it just belongs to the wrong request. Logged credentials are logged correctly — the credential reaches the log file without error. The defect is not a malfunction. It is a malfunction only in cost or security consequence. Tests that check output pass. Tests that check cost or security consequence: mostly unwritten.

Condition 2: No Complexity Tests in CI

Dijkstra said 'testing shows the presence of defects, not their absence.' Hamming extended this: the defects we test for are the defects we find. CI pipelines in 2026 test: correctness, type safety, API contracts, functional behavior. They do not test: algorithmic complexity per operation, per-call memory growth, authorization-header scrubbing, thread identity lifecycle.

No test is run. No test fails. The pipeline is green. The defect is invisible.

Condition 3: Small-N Origin

Code is written and reviewed in development environments. Development graphs have 50 nodes. Development request loads have 10 concurrent threads. Development cache miss rates are low (warm cache, few keys). At N=50 the O(N²) cost is 2,500 operations. Invisible. At N=50,000 the cost is 2,500,000,000 operations. A 17-minute build instead of a 1-second build.

The author who wrote the code never saw N=50,000. The reviewer who approved it never saw N=50,000. The defect was not visible at the scale of its writing.

Condition 4: Copy Propagates Without Context

A correct algorithm is instructive. Tutorials teach with correct examples. Documentation shows working code. The same Tarjan SCC skeleton — visited = [], inner if n not in visited — appears in GHC, Maven, Python pip, Cargo, TypeScript compiler, Kotlin compiler, Scala compiler, and javac. Different teams, different languages, different decades. Same fossil. The original author's N=50 does not propagate with the code. What propagates: the correct output. What stays behind: the performance assumption.

Condition 5: Scale Grows Around Frozen Code

Code does not degrade. Infrastructure scales. A dependency resolver written in 2003 for 200 packages runs on 50,000 packages in 2024. Nobody rewrites it — it works. Nobody profiles it — the CI is green. The N that makes the O(N²) cost catastrophic arrives gradually, invisibly, at production scale. By then the original author is gone. The code is a dependency. Nobody touches working dependencies.

Diagnosis: Five Conditions

The five conditions: correct output, no complexity tests, small-N origin, copy without context, scale grows around frozen code.

All five were present for every MOAD simultaneously. This is not coincidence — it is the structural signature of a sedimentary defect class.

What Hamming Said

Richard Hamming's 1986 lectures at Bell Labs — published in 1997 as The Art of Doing Science and Engineering — contain warnings that read as direct descriptions of the MOAD defect pattern. He was not describing MOAD. He was describing the structural tendency of engineering systems to calcify around locally correct decisions that become globally expensive.

Hamming on complexity: 'The purpose of computing is insight, not numbers. But you have to have the right complexity of algorithm or the numbers will never come. An O(N²) algorithm that runs on N=100 will not run on N=1,000,000 before you retire.'

Hamming on copy: 'Great engineers do not just copy solutions. They understand why the solution works, under what conditions it holds, & what would break it. A copied solution without its conditions is a time bomb.'

Hamming on testing: 'Testing what you measured is not the same as measuring what matters. We build elaborate test suites for the properties we chose to test. We leave untested the properties we did not choose. What we leave untested is what surprises us in production.'

Hamming on scale: 'The error you make in the first year of a project is the error you are still correcting in the tenth year. Early assumptions calcify. The project scales around them. Nobody rewrites the foundation.'

The Gap Between Warning and Operationalization

Hamming's warnings were correct. They were taught. They were cited. They were assigned in curricula. But a warning is not a detector. Hamming described the shape of the defect. He did not build a tool that runs in CI and flags O(N²) hot paths, ThreadLocal identity leaks, or credential logging. The gap between 'knowable' and 'detectable' is the gap between a theory and its operationalization as automated infrastructure.

MOAD exists because the field built correctness infrastructure and not performance or security infrastructure at the same level. Unit tests: standard since the 1970s. Property-based tests: standard since the 1990s. Algorithmic complexity benchmarks in CI: still experimental in 2026.

Operationalizing the Warning

Hamming warned about complexity calcification, untested properties, copied solutions without their conditions, & scale crushing early assumptions. He gave us the vocabulary. He did not give us the detector.

The MOAD pipeline fills that gap: scan → ticket → patch → unit test → disclose → PR → upstream merge. This is operationalized Hamming: not just the warning, but automated detection & a fix pipeline.

The Fester Signature

A MOAD-class defect has a recognizable signature. All five conditions present simultaneously. All five are checkable before writing a single scan:

1. Correct output? Run the standard test suite. If it passes, the defect is a performance or security property, not a correctness one. This means standard CI will not catch it.

2. No complexity test? Check the CI config. Is there a benchmark stage? Does it compare algorithmic behavior (not just wall time) against a prior commit? If not: condition present.

3. Small-N origin? Check the git blame & the original commit. What was the dataset size in the first implementation? Is that size smaller than current production load by more than 100×? If yes: condition present.

4. Copy propagates? Search for the pattern across the codebase & across ecosystems. Does the same structural pattern appear in N≥3 independent codebases with no shared ancestry? If yes: the fossil has propagated. Each copy: a new fester site.

5. Scale grows? Check the production metrics. What is N today vs. N at first deployment? Is the growth rate sustained? At what N does the defect become operationally critical?

If all five are checked and confirmed: you have a MOAD-class defect. The fix is always a one-line or one-method substitution. The discovery is the hard part. The fix is the easy part.

This is what Hamming meant: engineering is not about the fix. The fix is straightforward once you see it. Engineering is about building the systems that let you see it.

Apply the Signature

The MOAD fester signature: correct output + no complexity test + small-N origin + copy propagates + scale grows.

This signature is not limited to the five MOAD defects. It describes a class of defect that persists in any system where correctness tests are the only automated quality gate.