Theorie Die Al Bestond
Elk MOAD-defect had een bekende oplossing decennia vóór systematische detectie in 2026. De defecten bleven niet bestaan omdat niemand beter wist. Ze bleven bestaan omdat weten niet hetzelfde is als detecteren.
MOAD-0001: O(N²) list.contains
Donald Knuth, 1973. The Art of Computer Programming, Volume 3: Sorting and Searching. Hash tables voor O(1) lookup volledig gespecificeerd, met analyse, in 1973. Het verschil tussen O(N) lineair zoeken en O(1) hash lookup — gedocumenteerd, geformaliseerd, veel geciteerd. Java leverde HashSet in 1.0 (1996). Python leverde set als first-class type in 2.4 (2004). De fix bestond 30 jaar voordat het een standaardidiom werd in elk ecosysteem.
Richard Hamming, 1986. Bell Labs-lezingen (later gepubliceerd als The Art of Doing Science and Engineering, 1997). Hamming onderwees expliciet algoritmische complexiteit, het verschil tussen correct en efficiënt, en het gevaar van systemen die op kleine schaal werken maar falen op grote schaal. Hij noemde het 'ontwerpen voor het probleem dat je vandaag ziet, niet voor het probleem dat je morgen zult tegenkomen.'
MOAD-0002: Gedeelde globale statuskoppeling
David Parnas, 1972. 'On the Criteria To Be Used in Decomposing Systems into Modules.' CACM, december 1972. Parnas betoogde dat modules moeten worden ontleed door informatieverberging — elke module bezit zijn eigen status, geen gedeelde muteerbare globals. Dit is de directe theoretische voorganger van de Intertangle-fix. Parnas was expliciet: gedeelde globale status creëert onzichtbare koppeling die testen niet onthult.
MOAD-0003: ThreadLocal-identiteitslek
Java 1.2, 1998. ThreadLocal werd geleverd als een standaardbibliotheekklasse in Java. Zodra thread-pooling en ThreadLocal samen bestonden, bestond het mechanisme voor het lek. Het defect is structureel: een drager waarvan de levensduur de thread is, niet de werkeenheid. Documentatie waarschuwde hiervoor al vroeg in de Java EE-levenscyclus.
MOAD-0004: Gelogde referenties
RFC 1945, 1996. HTTP/1.0 definieerde de Authorization-header. Het defect van het loggen van referenties werd mogelijk op de dag dat de Authorization-header bestond. OWASP werd opgericht in 2001 en documenteerde het loggen van referenties als een kwetsbaarheidsklasse in haar eerste handleidingen. Het patroon: Authorization-header → log-middleware → tekstuele referenties op schijf. Wetenbaar sinds de eerste HTTP-authenticatiespecificatie.
MOAD-0005: Thundering Herd / Cache Stampede
Unix-kernel, 1993. Het 'thundering herd problem' — N processen die gelijktijdig worden gewekt bij een gedeelde gebeurtenis — verscheen in discussies over de Unix-kernelontwikkeling begin jaren negentig. Doug Schmidts werk aan het Reactor-patroon (1994) en Half-Sync/Half-Async (1995) richtte zich op synchronisatie op infrastructuurniveau. De cache-stampedevariant (N threads berekenen dezelfde waarde bij een cache-miss) werd in 2001 gedocumenteerd in de literatuur over gedistribueerde systemen.
---
Theorie: compleet. Detectie-instrumenten: afwezig. De kloof tussen 'knowable' en 'detected' loopt van 28 tot 54 jaar, afhankelijk van het defect.
De Knowability Gap
De tijdlijn toont dat elk MOAD-defect een bekende oplossing had, minstens 28 jaar vóór systematische detectie. De kortste kloof (MOAD-0003) bedraagt 28 jaar. De langste (MOAD-0002) bedraagt 54 jaar.
Dit is geen verhaal over onwetendheid. Knuth, Parnas, Hamming — dit zijn de meest geciteerde auteurs in de informatica. Hun werk werd toegewezen aan universiteiten. Hun vocabulaire (Big O, information hiding, algoritmische complexiteit) werd standaardcurriculum.
Waarom code blijft voortbestaan: vijf voorwaarden
Een defect blijft niet per ongeluk bestaan. Vijf structurele voorwaarden, die allemaal tegelijk aanwezig zijn, creëren een omgeving waarin het defect kan voortbestaan. Verwijder er één en detectie wordt mogelijk.
Voorwaarde 1: Correcte uitvoer
Een lijst en een set beantwoorden de membership-vraag identiek. list.contains(x) en set.contains(x) geven dezelfde boolean terug. Een ThreadLocal met verouderde identiteit draagt nog steeds een identiteit — maar die hoort bij het verkeerde verzoek. Ingelogde credentials worden correct gelogd — de credential bereikt het logbestand zonder fout. Het defect is geen storing. Het is alleen een storing in kosten of beveiligingsgevolgen. Tests die output controleren slagen. Tests die kosten of beveiligingsgevolgen controleren: grotendeels ongeschreven.
Voorwaarde 2: Geen complexiteitstests in CI
Dijkstra zei: 'testen toont de aanwezigheid van defecten aan, niet hun afwezigheid.' Hamming voegde hieraan toe: de defecten waarvoor we testen zijn de defecten die we vinden. CI-pipelines in 2026 testen: correctheid, typeveiligheid, API-contracten, functioneel gedrag. Ze testen niet: algoritmische complexiteit per operatie, geheugengroei per aanroep, scrubbing van autorisatie-headers, levenscyclus van thread-identiteit.
Er wordt geen test uitgevoerd. Geen test faalt. De pipeline is groen. Het defect is onzichtbaar.
Voorwaarde 3: Small-N oorsprong
Code wordt geschreven en beoordeeld in ontwikkelomgevingen. Ontwikkelgrafieken hebben 50 knooppunten. Ontwikkelverzoeken hebben 10 gelijktijdige threads. Cache-miss rates in ontwikkeling zijn laag (warme cache, weinig sleutels). Bij N=50 bedraagt de O(N²)-kosten 2.500 operaties. Onzichtbaar. Bij N=50.000 bedraagt de kosten 2.500.000.000 operaties. Een build van 17 minuten in plaats van 1 seconde.
De auteur die de code schreef, heeft N=50.000 nooit gezien. De reviewer die het goedkeurde, heeft N=50.000 nooit gezien. Het defect was niet zichtbaar op de schaal waarop het werd geschreven.
Voorwaarde 4: Copy verspreidt zich zonder context
Een correct algoritme is instructief. Tutorials onderwijzen met correcte voorbeelden. Documentatie toont werkende code. Dezelfde Tarjan SCC-skelet — visited = [], inner if n not in visited — verschijnt in GHC, Maven, Python pip, Cargo, TypeScript-compiler, Kotlin-compiler, Scala-compiler en javac. Verschillende teams, verschillende talen, verschillende decennia. Dezelfde fossiel. De N=50 van de oorspronkelijke auteur verspreidt zich niet met de code. Wat zich verspreidt: de correcte uitvoer. Wat achterblijft: de prestatie-aanname.
Voorwaarde 5: Schaal groeit rond bevroren code
Code degenereert niet. Infrastructuur schaalt. Een afhankelijkheidsoplosser geschreven in 2003 voor 200 pakketten draait op 50.000 pakketten in 2024. Niemand herschrijft het — het werkt. Niemand profileert het — de CI is groen. De N die de O(N²)-kosten catastrofaal maakt, komt geleidelijk, onzichtbaar, op productieschaal. Tegen die tijd is de oorspronkelijke auteur verdwenen. De code is een afhankelijkheid. Niemand raakt werkende afhankelijkheden aan.
Diagnose: Vijf voorwaarden
De vijf voorwaarden: correcte uitvoer, geen complexiteitstests, oorsprong met kleine N, kopiëren zonder context, schaal groeit rond bevroren code.
Alle vijf waren aanwezig bij elke MOAD tegelijk. Dit is geen toeval — het is de structurele signatuur van een sedimentaire defectklasse.
Wat Hamming zei
Richard Hamming's lezingen uit 1986 bij Bell Labs — gepubliceerd in 1997 als The Art of Doing Science and Engineering — bevatten waarschuwingen die als directe beschrijvingen van het MOAD-defectpatroon kunnen worden gelezen. Hij beschreef niet MOAD. Hij beschreef de structurele neiging van technische systemen om te verkalken rond lokaal correcte beslissingen die globaal kostbaar worden.
Hamming over complexiteit: 'Het doel van computing is inzicht, niet getallen. Maar je moet de juiste complexiteit van algoritme hebben, anders komen de getallen nooit. Een O(N²)-algoritme dat draait op N=100, zal niet draaien op N=1.000.000 voordat je met pensioen gaat.'
Hamming over kopiëren: 'Grote engineers kopiëren geen oplossingen zomaar. Ze begrijpen waarom de oplossing werkt, onder welke voorwaarden hij geldt, en wat hem zou breken. Een gekopieerde oplossing zonder zijn voorwaarden is een tijdbom.'
Hamming over testen: 'Testen wat je hebt gemeten is niet hetzelfde als meten wat ertoe doet. We bouwen uitgebreide testsuites voor de eigenschappen die we hebben gekozen om te testen. We laten ongetest wat we niet hebben gekozen. Wat we ongetest laten, is wat ons verrast in productie.'
Hamming op schaal: 'De fout die je maakt in het eerste jaar van een project is de fout die je nog steeds corrigeert in het tiende jaar. Vroege aannames verkalken. Het project schaalt eromheen. Niemand herschrijft de fundering.'
De kloof tussen waarschuwing en operationalisering
Hamming's waarschuwingen waren correct. Ze werden onderwezen. Ze werden geciteerd. Ze werden toegewezen in curricula. Maar een waarschuwing is geen detector. Hamming beschreef de vorm van het defect. Hij bouwde geen tool die in CI draait en O(N²) hot paths, ThreadLocal-identiteitslekken of credential-logging markeert. De kloof tussen 'kenbaar' en 'detecteerbaar' is de kloof tussen een theorie en de operationalisering ervan als geautomatiseerde infrastructuur.
MOAD bestaat omdat het vakgebied correctheidsinfrastructuur heeft gebouwd en geen prestatie- of beveiligingsinfrastructuur op hetzelfde niveau. Unittests: standaard sinds de jaren 1970. Property-based tests: standaard sinds de jaren 1990. Algoritmische-complexiteitsbenchmarks in CI: nog steeds experimenteel in 2026.
Operationalisering van de waarschuwing
Hamming waarschuwde voor complexiteitsverkalking, ongeteste eigenschappen, gekopieerde oplossingen zonder hun voorwaarden, & schaal die vroege aannames verplettert. Hij gaf ons de woordenschat. Hij gaf ons de detector niet.
De MOAD-pipeline vult die kloof: scan → ticket → patch → unittests → openbaarmaking → PR → upstream-merge. Dit is geoperationaliseerde Hamming: niet alleen de waarschuwing, maar geautomatiseerde detectie & een fix-pipeline.
De Fester Signature
Een MOAD-class defect heeft een herkenbare signature. Alle vijf voorwaarden zijn tegelijkertijd aanwezig. Alle vijf zijn controleerbaar voordat er ook maar één scan wordt geschreven:
1. Correcte output? Voer de standaard test-suite uit. Als deze slaagt, is het defect een performance- of security-eigenschap, geen correctheidseigenschap. Dit betekent dat standaard CI het niet zal opvangen.
2. Geen complexiteitstest? Controleer de CI-configuratie. Is er een benchmark-fase? Vergelijkt deze het algoritmisch gedrag (niet alleen de wall time) met een eerdere commit? Zo niet: conditie aanwezig.
3. Small-N oorsprong? Controleer de git blame en de originele commit. Wat was de datasetgrootte in de eerste implementatie? Is die grootte meer dan 100× kleiner dan de huidige productiebelasting? Zo ja: conditie aanwezig.
4. Kopie verspreidt zich? Zoek naar het patroon in de codebase en in verschillende ecosystemen. Komt hetzelfde structurele patroon voor in N≥3 onafhankelijke codebases zonder gedeelde oorsprong? Zo ja: het fossiel heeft zich verspreid. Elke kopie: een nieuwe broedplaats.
5. Schaal groeit? Controleer de productie-metrics. Wat is N vandaag vergeleken met N bij de eerste uitrol? Is de groeisnelheid aanhoudend? Bij welke N wordt het defect operationeel kritiek?
Als alle vijf zijn gecontroleerd en bevestigd: je hebt een MOAD-klasse defect. De oplossing is altijd een één-regelige of één-methode substitutie. Het ontdekken is het moeilijke deel. De oplossing is het makkelijke deel.
Dit is wat Hamming bedoelde: engineering gaat niet over de oplossing. De oplossing is eenvoudig zodra je hem ziet. Engineering gaat over het bouwen van systemen die je in staat stellen hem te zien.
Pas de Signature toe
De MOAD-fester signature: correcte output + geen complexiteitstest + small-N oorsprong + kopie verspreidt zich + schaal groeit.
Deze signature is niet beperkt tot de vijf MOAD-defecten. Het beschrijft een klasse van defecten die blijft bestaan in elk systeem waarbij correctheidstests de enige geautomatiseerde kwaliteitscontrole zijn.