Teori som redan existerade
Varje MOAD-defekt hade en känd lösning årtionden innan systematisk upptäckt 2026. Defekterna bestod inte för att ingen visste bättre. De bestod för att veta inte är detsamma som att upptäcka.
MOAD-0001: O(N²) list.contains
Donald Knuth, 1973. The Art of Computer Programming, Volume 3: Sorting and Searching. Hashtabeller för O(1)-uppslagning fullt specificerade, med analys, 1973. Skillnaden mellan O(N) linjär sökning och O(1) hash-uppslagning — dokumenterad, formaliserad, allmänt citerad. Java levererade HashSet i 1.0 (1996). Python levererade set som en förstklassig typ i 2.4 (2004). Fixen existerade i 30 år innan den blev ett standardidiom i varje ekosystem.
Richard Hamming, 1986. Bell Labs-föreläsningar (senare publicerade som The Art of Doing Science and Engineering, 1997). Hamming undervisade explicit om algoritmisk komplexitet, skillnaden mellan korrekt och effektiv, samt risken med att bygga system som fungerar i liten skala men fallerar i stor skala. Han kallade det ”att designa för problemet du ser idag, inte för problemet du kommer att möta imorgon.”
MOAD-0002: Delat globalt tillståndskoppling
David Parnas, 1972. ”On the Criteria To Be Used in Decomposing Systems into Modules.” CACM, december 1972. Parnas argumenterade för att moduler bör delas upp genom information hiding – varje modul äger sitt eget tillstånd, inga delade muterbara globaler. Detta är den direkta teoretiska föregångaren till Intertangle-fixet. Parnas var tydlig: globalt delat tillstånd skapar osynlig koppling som tester inte avslöjar.
MOAD-0003: ThreadLocal Identity Leak
Java 1.2, 1998. ThreadLocal levererades som en standardklass i Java. I samma ögonblick som trådpoolning och ThreadLocal samexisterade uppstod mekanismen för läckan. Defekten är strukturell: en bärare vars livstid är tråden, inte arbetsenheten. Dokumentationen varnade för detta redan tidigt i Java EE:s livscykel.
MOAD-0004: Loggade inloggningsuppgifter
RFC 1945, 1996. HTTP/1.0 definierade Authorization-huvudet. Defekten med loggning av inloggningsuppgifter blev möjlig samma dag som Authorization-huvudet infördes. OWASP grundades 2001 och dokumenterade loggning av inloggningsuppgifter som en sårbarhetsklass i sina första guider. Mönstret: Authorization-huvud → logg-mellanvara → klartextuppgifter på disk. Känd sedan den första HTTP-auth-specifikationen.
MOAD-0005: Thundering Herd / Cache Stampede
Unix-kärnan, 1993. Problemet med "thundering herd" — N processer som väcks samtidigt vid en delad händelse — dök upp i diskussioner om Unix-kärnans utveckling redan i början av 1990-talet. Doug Schmidts arbete med Reactor-mönstret (1994) och Half-Sync/Half-Async (1995) hanterade synkronisering på infrastrukturnivå. Varianten med cache stampede (N trådar beräknar samma värde vid cache-miss) dokumenterades i litteraturen om distribuerade system år 2001.
---
Teori: fullständig. Detekteringsverktyg: saknas. Gapet mellan "knowable" och "detected" sträcker sig från 28 till 54 år beroende på defekten.
The Knowability Gap
Tidslinjen visar att varje MOAD-defekt hade en känd lösning minst 28 år innan systematisk detektering. Det kortaste gapet (MOAD-0003) är 28 år. Det längsta (MOAD-0002) är 54 år.
Detta är inte en historia om okunskap. Knuth, Parnas, Hamming — dessa är de mest citerade författarna inom datavetenskap. Deras verk användes i universitetsundervisning. Deras vokabulär (Big O, information hiding, algoritmisk komplexitet) blev standard i läroplaner.
Varför kod frodas: Fem villkor
Ett fel består inte av en slump. Fem strukturella villkor, alla närvarande samtidigt, skapar en grogrund. Ta bort ett av dem och upptäckt blir möjlig.
Villkor 1: Korrekt utdata
En lista och en mängd besvarar medlemskapsfrågan identiskt. list.contains(x) och set.contains(x) returnerar samma boolean. En ThreadLocal som bär en föråldrad identitet bär fortfarande en identitet — den tillhör bara fel begäran. Inloggade autentiseringsuppgifter loggas korrekt — autentiseringsuppgifterna når loggfilen utan fel. Felet är inte en funktionsstörning. Det är en funktionsstörning endast i kostnads- eller säkerhetskonsekvens. Tester som kontrollerar utdata passerar. Tester som kontrollerar kostnads- eller säkerhetskonsekvens: mestadels oskrivna.
Villkor 2: Inga komplexitetstester i CI
Dijkstra sa: ”testning visar förekomsten av fel, inte deras frånvaro.” Hamming utvidgade detta: de fel vi testar för är de fel vi hittar. CI-pipelines 2026 testar: korrekthet, typsäkerhet, API-kontrakt, funktionellt beteende. De testar inte: algoritmisk komplexitet per operation, minnesökning per anrop, rensning av auktoriseringshuvuden, livscykel för trådidentitet.
Inget test körs. Inget test misslyckas. Pipelinen är grön. Felet är osynligt.
Villkor 3: Small-N-ursprung
Koden skrivs och granskas i utvecklingsmiljöer. Utvecklingsgrafer har 50 noder. Utvecklingsbegäranden har 10 samtidiga trådar. Cache-missfrekvensen i utveckling är låg (varm cache, få nycklar). Vid N=50 är O(N²)-kostnaden 2 500 operationer. Osynlig. Vid N=50 000 är kostnaden 2 500 000 000 operationer. En 17-minuters build istället för en 1-sekunders build.
Författaren som skrev koden såg aldrig N=50 000. Granskaren som godkände den såg aldrig N=50 000. Felet var inte synligt i den skala det skrevs.
Villkor 4: Kopiering sprids utan kontext
En korrekt algoritm är instruktiv. Handledningar lär ut med korrekta exempel. Dokumentation visar fungerande kod. Samma Tarjan SCC-skelett — visited = [], inre if n not in visited — förekommer i GHC, Maven, Python pip, Cargo, TypeScript-kompilatorn, Kotlin-kompilatorn, Scala-kompilatorn och javac. Olika team, olika språk, olika decennier. Samma fossil. Den ursprungliga författarens N=50 sprids inte med koden. Det som sprids: det korrekta resultatet. Det som lämnas kvar: prestandaantagandet.
Villkor 5: Skala växer runt frusen kod
Kod försämras inte. Infrastruktur skalas. En beroendehanterare skriven 2003 för 200 paket körs på 50 000 paket 2024. Ingen skriver om den — den fungerar. Ingen profilerar den — CI:n är grön. Det N som gör O(N²)-kostnaden katastrofal kommer gradvis, osynligt, i produktionsskala. Då är den ursprungliga författaren borta. Koden är ett beroende. Ingen rör fungerande beroenden.
Diagnos: Fem villkor
De fem villkoren: korrekt utdata, inga komplexitetstester, ursprung med litet N, kopiering utan kontext, skala växer runt frusen kod.
Alla fem var närvarande för varje MOAD samtidigt. Detta är ingen slump — det är den strukturella signaturen för en sedimentär defektklass.
Vad Hamming sa
Richard Hammings föreläsningar från 1986 på Bell Labs — publicerade 1997 som The Art of Doing Science and Engineering — innehåller varningar som direkt beskriver MOAD-defektmönstret. Han beskrev inte MOAD. Han beskrev den strukturella tendensen hos ingenjörssystem att stelna kring lokalt korrekta beslut som blir globalt kostsamma.
Hamming om komplexitet: ”Syftet med beräkning är insikt, inte siffror. Men du måste ha rätt komplexitet hos algoritmen, annars kommer siffrorna aldrig fram. En O(N²)-algoritm som körs på N=100 kommer inte att köra på N=1 000 000 innan du går i pension.”
Hamming om kopiering: ”Bra ingenjörer kopierar inte bara lösningar. De förstår varför lösningen fungerar, under vilka villkor den gäller och vad som skulle bryta den. En kopierad lösning utan sina villkor är en tickande bomb.”
Hamming om testning: ”Att testa det du mätte är inte detsamma som att mäta det som spelar roll. Vi bygger detaljerade testsviter för de egenskaper vi valt att testa. Vi lämnar otestade de egenskaper vi inte valt. Det vi lämnar otestat är det som överraskar oss i produktion.”
Hamming om skala: 'Felet du gör under det första året av ett projekt är det fel du fortfarande rättar till under det tionde året. Tidiga antaganden förstenas. Projektet skalas runt dem. Ingen skriver om grunden.'
Gapet mellan varning och operationalisering
Hammings varningar var korrekta. De undervisades. De citerades. De tilldelades i läroplaner. Men en varning är inte en detektor. Hamming beskrev defektens form. Han byggde inte ett verktyg som körs i CI och flaggar O(N²)-heta sökvägar, ThreadLocal-identitetsläckor eller loggning av autentiseringsuppgifter. Gapet mellan 'vetbart' och 'detekterbart' är gapet mellan en teori och dess operationalisering som automatiserad infrastruktur.
MOAD existerar eftersom fältet byggde korrekthetsinfrastruktur men inte prestanda- eller säkerhetsinfrastruktur på samma nivå. Enhetstester: standard sedan 1970-talet. Egenskapsbaserade tester: standard sedan 1990-talet. Algoritmiska komplexitetsbenchmarkar i CI: fortfarande experimentella 2026.
Operationalisera varningen
Hamming varnade för komplexitetsförstening, otestade egenskaper, kopierade lösningar utan deras villkor, och skala som krossar tidiga antaganden. Han gav oss vokabulären. Han gav oss inte detektorn.
MOAD-pipelinen fyller det gapet: skanna → ärende → patch → enhetstest → avslöja → PR → upstream-merge. Detta är operationaliserad Hamming: inte bara varningen, utan automatiserad detektering och en fix-pipeline.
Fester-signaturen
En MOAD-klassdefekt har en igenkännbar signatur. Alla fem villkor är samtidigt uppfyllda. Alla fem kan kontrolleras innan en enda skanning skrivs:
1. Korrekt utdata? Kör den vanliga testsviten. Om den passerar är defekten en prestanda- eller säkerhetsegenskap, inte en korrekthetsfråga. Det innebär att standard-CI inte kommer att fånga den.
2. Inget komplexitetstest? Kontrollera CI-konfigurationen. Finns det ett benchmark-steg? Jämför det algoritmiskt beteende (inte bara väggtid) mot en tidigare commit? Om inte: villkor föreligger.
3. Small-N-ursprung? Kontrollera git blame och den ursprungliga commiten. Hur stor var datasetet i den första implementationen? Är den storleken mer än 100× mindre än nuvarande produktionslast? Om ja: villkor föreligger.
4. Kopia sprids? Sök efter mönstret i kodbasen och över ekosystem. Finns samma strukturella mönster i N≥3 oberoende kodbaser utan gemensamt ursprung? Om ja: fossilet har spridits. Varje kopia: en ny infekterad plats.
5. Skala växer? Kontrollera produktionsmåtten. Vad är N idag jämfört med N vid första driftsättningen? Är tillväxttakten hållbar? Vid vilket N blir defekten operationellt kritisk?
Om alla fem är kontrollerade och bekräftade: du har en MOAD-klassdefekt. Fixen är alltid en enradig eller en-metod-substitution. Upptäckten är den svåra delen. Fixen är den enkla delen.
Detta är vad Hamming menade: ingenjörskonst handlar inte om fixen. Fixen är enkel när man väl ser den. Ingenjörskonst handlar om att bygga system som låter dig se den.
Tillämpa signaturen
MOAD-festersignaturen: korrekt utdata + inget komplexitetstest + small-N-ursprung + kopia sprids + skala växer.
Denna signatur är inte begränsad till de fem MOAD-felen. Den beskriver en klass av fel som kvarstår i alla system där korrekthetstester är den enda automatiserade kvalitetsgrinden.