Optimaliseer het systeem, niet de componenten
Hamming's eerste regel van systeemengineering
Hamming's kernprincipe uit Hfd. 28: Als je de componenten optimaliseert, verpest je waarschijnlijk de systeemprestaties.
Hij illustreerde dit met het verhaal van de differentiaalanalysator. Twee eenheden moesten worden verbonden. De bouwers verbeterden de versterkers in de tweede eenheid. Op de acceptatiedag voerde Hamming de standaardtest uit — los y'' + y = 0 op, plot y vs y', verwacht een cirkel. Het mislukte. De oorzaak: verbeterde versterkers trokken meer stroom door het aardingscircuit. De aarding was prima voor het oorspronkelijke ontwerp. Hij was niet berekend op het nieuwe stroomniveau. De interface brak, niet de component.
Zijn generalisatie: de meeste systeemstoringen zijn te herleiden tot interfaces, niet tot componenten. Componenten worden ontworpen, getest en gecertificeerd. Interfaces worden als bijzaak ontworpen, zelden getest en nooit onafhankelijk gecertificeerd. Wanneer een component verandert, verandert ook het gedrag van de interface. Niets stroomafwaarts is ontworpen voor die nieuwe interface.
Belangrijke asymmetrie: een 10× verbetering in een component kan een 10× verslechtering van het systeem veroorzaken als de component een beperkte interface voedt. De verbetering telt niet op — ze trekt af.
Het onderwijssysteem als mislukte systeemengineering
Hammings onderwijsvoorbeeld
Hamming paste dit principe toe op onderwijs. Het optimaliseren van individuele vakscores — leerlingen drillen om maximale testprestaties per vak te behalen — levert leerlingen op die goed scoren op individuele toetsen, maar kennis niet kunnen integreren over disciplines heen.
Elk onderdeel (vakscore) verbetert. Het systeem (onderwijs, gedefinieerd als geïntegreerd begrip) verslechtert. De interface tussen vakken — het vermogen van de student om kennis over domeinen heen toe te passen — werd nooit geoptimaliseerd. Het atrofieerde.
Dit is geen toeval van implementatie. Het is structureel. Wanneer je onderdeelprestaties meet en beloont, krijg je optimalisatie van onderdelen. Interfaces zijn onzichtbaar voor metrieken op onderdeelniveau.
Zijn voorschrift: vind de bottleneck in het systeem, en vraag vervolgens wat er downstream gebeurt als je die verwijdert. Het wegnemen van een bottleneck laat de volgende wachtrij vollopen. Een ongehinderde optimalisatie wordt een nieuwe beperking.
Interface-degradatie traceren
Hamming toonde aan dat het verbeteren van een onderdeel het interface-gedrag verandert — en de rest van het systeem was ontworpen rond de oude interface.
Nodes, queues, surge scores
Een MOAD-fabrieksmodel
Elke software-afhankelijkheidsgraaf vormt een fabriek. Elke node is een werkstation. Elke edge is een wachtrij. Werk komt binnen in de wachtrij van een node, wordt verwerkt en stroomt door naar downstream-wachtrijen.
Twee scores karakteriseren elke node:
Surge score = speedup × in-degree
Hoeveel werk stroomt downstream wanneer deze bottleneck wordt opgeheven. Een node met in-degree 5 (5 upstream afhankelijkheden die er allemaal naartoe stromen) en een 100× speedup genereert 500× surge downstream.
Betweenness = in-degree + out-degree
Hoe centraal dit werkstation is voor de totale flow. Hoge betweenness betekent dat veel paden door deze node lopen.
Twee archetypen:
Workaholic-node: hoge betweenness, hoge surge-score. Dit is de bottleneck. Elke wachtrij stroomopwaarts loopt vast door deze node. Verwijder je deze bottleneck zonder downstream-capaciteit te faseren, dan stort alles stroomafwaarts tegelijk in.
Glutton-node: hoge out-degree, lage surge-score. Verbruikt alles wat eraan wordt gevoerd. Voelt geen pijn omdat de bottleneck intern is, niet in de doorvoer. De machine die vergeet te stoppen — werk komt binnen, niets gaat eruit, en de node meldt eeuwig 'bezig'.
MOAD-0001 & MOAD-0005: Een koppelingsscenario
Het GHC-geval
Voor een MOAD-0001-patch in GHC's dependency resolver: N=50.000 afhankelijkheden duurden 17 minuten om te bouwen. Na: 10 seconden. Versnelling: 100×.
Wat gebeurt er downstream? Elke build-cache, artifact store en CI-runner die zich had aangepast aan 17-minuten batches ontvangt nu 100× meer voltooide builds per uur. Caches die ontworpen waren voor 60 build-artifacts per uur ontvangen nu 6.000.
Dit is MOAD-0005: het cache-stampededefect. Elke cache-sleutel mist tegelijkertijd omdat geen enkele cache was voorverwarmd voor de nieuwe aankomstsnelheid. De fix voor MOAD-0001 veroorzaakt MOAD-0005.
De koppeling is niet toevallig. Hij is structureel. Elke O(N²) → O(N)-versnelling met in-degree > 1 produceert een surge-score boven 1. Een surge-score boven 100 is een MOAD-0005-kandidaat.
Staging Before Disclosure
Een buildsysteem verwerkt 1.000 pakketafhankelijkheidsgrafieken per uur. Je past MOAD-0001 toe in de grafiektraversal, waardoor de bouwtijd daalt van 60 minuten naar 30 seconden — een versnelling van 120×. Het systeem verwerkt nu 120.000 grafieken per uur.
Wanneer stoppen: de Halt Condition
De Halt-conditie
Een patch voldoet aan de halt-conditie — wat betekent: niet openbaar maken — wanneer alle vier voorwaarden tegelijk gelden:
1. Patch bevindt zich in een live systeem (samengevoegd, uitgerold)
2. Geen caretakers toegewezen om de downstream-impact te beheren
3. Downstream-defect (MOAD-0005) onopgelost
4. Speedup >= 100×
Alle vier samen = de baby huilt. Wijs het team toe vóór het samenvoegen, niet erna.
Een node zonder verzorger draait als een werkstation zonder medewerker. Werk stapelt zich op. Iemand bezwijkt. Het permacomputer-principe: je repareert het dispatch-algoritme niet zonder de chauffeurs te faseren. Drie chauffeurs, drie miljoen mensen: het ontgrendelen van het algoritme creëert een thundering herd van onvervulde verzoeken in plaats van snellere levering.
WALL-E: Gluttons & Workaholics
Het WALL-E-model
Pixar’s WALL-E toont een fabrieksmodel-fout in zijn duidelijkste vorm. Gluttons op hoverstoelen, gevoed zonder wrijving. Workaholics — WALL-E, EVE — stervend aan hun stations om de toevoer draaiende te houden.
De glutton-node (de mensen op hoverstoelen) heeft maximale out-degree: hij consumeert alles wat hem wordt gevoed, produceert niets. Zijn surge-score is nul — het is een sink. Hij voelt geen pijn omdat er niets ophoopt aan zijn uitgang. Hij consumeert gewoon.
De workaholic-node (WALL-E) heeft de hoogste betweenness: alles stroomt erdoorheen. Het absorbeert alle input. Het produceert de enige output. De surge-score, als het ooit door een sneller model zou worden vervangen, zou alle downstream-wachtrijen tegelijkertijd overspoelen.
Het defect in het WALL-E-systeem zit niet bij de gluttons. Het zit bij de afwezige caretaker: niemand is toegewezen om de werkstations in balans te brengen. Niemand heeft de capaciteit voorbereid voordat het algoritme werd uitgevoerd.
De pip Case: Pre-Disclosure Checklist
Je ontdekt MOAD-0001 in Python's pip dependency resolver. Gemeten versnelling: 200×. pip draait op ongeveer 400 miljoen installs per dag. PyPI serveert de packages.