Drei Phasen der Computeranwendung
Hammings Kapitel 5 beginnt mit einem Rückblick: seine 30-jährige Serie von Präsentationen bei IBM-Kundenschulungen zwang ihn, Trends zu verstehen, nicht nur Fakten. Die wiederholte Vorbereitung desselben Talks erforderte, dass er dem Feld voraus blieb, nicht nur aktuell.
Er identifizierte drei aufeinanderfolgende Phasen, wie Computer angewendet wurden:
Phase 1: Hardware-Grenzen (Kapitel 3). Early Computing war durch das begrenzt, was die Maschine konnte — Speicher war knapp, Zyklen waren teuer, Zuverlässigkeit war unsicher. Anwendungen wurden gewählt, um zur Hardware zu passen.
Phase 2: Software-Grenzen (Kapitel 4). Während sich die Hardware verbesserte, wurde Programmierung zum Engpass. Anwendungen waren durch das begrenzt, was effizient kodiert werden konnte.
Phase 3: Wirtschaft & Anwendungen (Kapitel 5). Gegen Ende der 1980er Jahre war Hardware billig genug & Software leistungsfähig genug, dass die Frage wurde: Was sollten Computer tun? Wirtschaft & organisatorische Kapazität bestimmten, welche Anwendungen gebaut wurden.
Dieser Phasenwechsel ist wichtig: jede Phase erforderte völlig unterschiedliche Fähigkeiten von Praktikern. Ein brillanter Hardware-Ingenieur aus Phase 1, der sein Mentales Modell nie aktualisierte, wurde in Phase 3 nutzlos.
Früheste Anwendungen
Computing begann mit astronomischer Berechnung, dann 'Zahlenrechnung' in Physik & Technik. Raymond Lull (1235–1315), ein spanischer Theologe, baute eine Logik-Maschine — die erste Anwendung von Computing auf nicht-numerisches Denken. Jonathan Swift verspottete sie in Gullivers Reisen (die Insel Laputa). Hamming verfolgte diese Linie von Lull durch symbolische Manipulation zu dem, was würde werden: maschinelles Lernen.
Die S-Kurve der Technologieeinführung
Jede große Technologie folgt einer charakteristischen Flugbahn: langsame anfängliche Adoption, schnelle Beschleunigung, Sättigung. Hamming nannte dies das S-Kurven-Muster.
Phase 1 einer beliebigen Technologie: heroische Demonstration. Eine kleine Anzahl von Enthusiasten demonstriert, dass die Technologie funktioniert. Fortschritt hängt von individuellem Genie & Toleranz für Unzuverlässigkeit ab.
Phase 2: schnelle Adoption. Die Technologie wird zuverlässig genug für allgemeine Verwendung. Infrastruktur baut sich darum auf. Standards entstehen. Der limitierende Faktor verschiebt sich von technisch zu organisatorisch.
Phase 3: Sättigung. Die Technologie erreicht volle Penetration ihres adressierbaren Marktes. Weitere Verbesserung bringt sinkende Erträge. Neue S-Kurven beginnen für Nachfolger-Technologien.
Für Computing: Phase 1 = ENIAC-Ära (1940er–1950er), Phase 2 = Mainframe-Kommerzialisierung (1960er–1970er), Phase 3 = Personalcomputing nähert sich der Sättigung (1980er–1990er). Hamming schrieb während des Übergangs von Phase 2 zu Phase 3 für Mainframes, während Personalcomputing noch in Phase 2 war.
Die Äquivalenzprodukt-Einsicht (zuerst in Kapitel 2 dargelegt) trifft hier direkt zu: in Phase 2 produziert erfolgreiche Computerisierung einen äquivalenten Job, nicht den gleichen Job. Organisationen, die versuchten, bestehende Arbeitsabläufe zu computerisieren, ohne sie umzugestalten, schlugen oft fehl oder zeigten schlechte Leistung.
Dich selbst auf der S-Kurve positionieren
Hammings S-Kurven-Einsicht hat eine praktische Implikation: die Fähigkeiten & Strategien, die in Phase 1 erfolgreich sind (heroisch, experimentell, hohe Fehlertoleranz), unterscheiden sich von denen, die in Phase 2 benötigt werden (zuverlässige Lieferung, Standards-Compliance, organisatorische Integration) und Phase 3 (Optimierung, Kostenreduktion, Plattform-Konsolidierung).
Wenn gemeinsame Daten nicht funktionieren
Hamming erzählte eine Geschichte aus seiner Zeit, als er ein hochrangiges Audit von Boeings Computer-Center durchführte. Boeings Management glaubte, sie hätten kollaboratives Design gelöst: Alle Ingenieure würden ihren aktuellen Entwurfsstatus auf ein gemeinsames Tape schreiben. Jeder würde aus dieser einzigen Wahrheitsquelle lesen. Koordinationsprobleme würden verschwinden.
Es funktionierte nicht.
Der Grund: Wenn ein Team eine Optimierungsstudie durchführt (z.B. Flügelbereich & -profil variiert, um Widerstand zu minimieren), benötigen sie einen festen Ausgangspunkt, um Änderungen dagegen zu messen. Wenn sich das gemeinsame Tape kontinuierlich mit Änderungen von anderen Teams aktualisiert, könnte eine Verbesserung, die ein Team misst, tatsächlich die Änderung von jemandem anderem widerspiegeln, die zwischen ihren Iterationen eingefügt wurde — nicht ihre eigene Design-Entscheidung.
Die Lösung, die Teams in der Praxis annahmen: Jede Gruppe erstellte zu Beginn einer Optimierungsstudie eine Snapshot-Kopie des aktuellen Tapes. Sie verwendeten diese eingefrorene Kopie während ihrer Studie und ignorierten Updates. Nur wenn sie mit ihrem neuen Design zufrieden waren, schrieben sie zurück — dann abgestimmt mit allen anderen Änderungen.
Hammings Schlussfolgerung: Man kann eine sich kontinuierlich ändernde Datenbank nicht für eine Optimierungsstudie verwenden. Die Optimierung erfordert einen stabilen Zustandsraum; ein änderbarer gemeinsamer Zustand führt Phantom-Korrelationen ein.
Datenbanken
Computer wurden als Lösung für organisatorische Datenprobleme gefördert. Hamming war skeptisch. Er zitierte Fluglinien-Reservierungssysteme als wirklich erfolgreich (das Koordinationsproblem ist real, das Datenmodell ist einfach, & Konsistenz ist streng erforderlich). Aber Management-Informationssysteme, die Managern 'den aktuellen Zustand des Unternehmens in Echtzeit' versprechen sollten, lieferten konsistent zu wenig: Die Datenmodelle waren zu komplex, Datenqualität zu schlecht, & Interpretation zu mehrdeutig.
Stabiler Ausgangspunkt vs Live-Daten
Der Boeing-Fehler illustriert ein allgemeines Prinzip, das Hamming implizierte: Optimierung erfordert eine stabile Kostenfunktion, die auf einem festen Zustandsraum bewertet wird. Ein gemeinsamer änderbarer Zustand verletzt die Anforderung des festen Zustandsraums.
Dieses Prinzip erstreckt sich über Software hinaus. In jedem Optimierungsprozess — Geschäftsstrategie, experimentelles Design, Modell-Training — erfordert die Isolierung der untersuchten Variablen die Kontrolle aller anderen.
Mustererkennung als die nächste Grenze
Bis 1993 identifizierte Hamming Mustererkennung als die große nächste Herausforderung für Computing. Er unterschied zwei Typen:
Klassische Mustererkennung: Vergleichen einer Eingabe mit einer gespeicherten Vorlage. Gesichtserkennung, OCR (optische Zeichenerkennung), Signatur-Verifikation. Diese lassen algorithmische Lösungen zu, wenn die Vorlage-Menge definiert ist.
Echte Erkennung: Ein Kind erkennt 'Stuhl' über Tausende verschiedener Formen, Materialien, Größen, & Ausrichtungen, ohne die meisten davon je gesehen zu haben. Keine explizite Vorlage deckt die Verallgemeinerung ab. Hamming behandelte dies als ein offenes Problem — die Lücke zwischen klassischer Muster-Zuordnung & echter Erkennung war keine Frage von mehr Daten oder schnellerer Hardware. Sie erforderte unterschiedliche Grundlagen.
Er rahmt dies in Bezug auf das Versagen von Expertensystemen: Forscher dachten, sie könnten Entscheidungsregeln von Experten extrahieren & in Programmen codieren. Expertensysteme funktionierte in engen Bereichen, aber scheiterte in komplexen, teilweise weil menschliche Experten Muster verwenden, die sie nicht artikulieren können. Die unbewusste Muster-Bibliothek, die über Jahre der Praxis aufgebaut wird, kann nicht durch Interviews extrahiert werden.
Hammings Vorhersage (1993): Echte Mustererkennung würde grundlegend unterschiedliche rechnergestützte Ansätze erfordern. Er deutete auf neuronale Netze hin, war aber vorsichtig — nicht überzeugt, dass die damaligen neuronalen Netze die Lücke schließen würden.
30 Jahre denselben Talk halten
Hamming beschrieb eine Praxis, die ihm mehr Ertrag gab als fast alles andere in seinem Berufsleben: denselben Talk wiederholt zu halten.
Er wurde eingeladen, bei IBM-Kundenschulungs-Veranstaltungen zu sprechen, etwa 1960. Er wählte, einen Talk über Die Geschichte der Datenverarbeitung bis zum Jahr 2000 zu halten — ein Thema, bei dem er wirklich unsicher war, was ihn zwang, aktuelle Ansichten zu entwickeln. Er gab Varianten dieses Talks zwei oder dreimal pro Jahr für 30 Jahre.
Die Vorteile, die er identifizierte:
Aktuell bleiben: denselben Talk wiederholt zu halten, zwang ihn, ihn regelmäßig zu aktualisieren. Er konnte keinen abgestandenen Talk geben, ohne sich vor Publikum zu blamieren, das das Feld verfolgte.
Trend-Erkennung: Der Update-Prozess zwang ihn, nach Trends zu suchen, nicht nur Ereignisse. Was änderte sich im letzten Jahr und in welche Richtung? Wiederholte Updates erforderten ein Modell des Feldes, nicht nur einen Katalog von Fakten.
Öffentliche Redner-Fähigkeit: Praxis reduzierte Angst & verbesserte die Lieferung. Er hörte auf, Angst vor Talks zu haben; er wurde durch Wiederholung eher ein polierter Redner als durch Talent.
Netzwerk: Ein konsistentes Thema baute einen Ruf auf. Menschen verbanden ihn mit Computing-Trends. Einladungen vervielfachten sich.
Seine Beobachtung: er hätte diese Praxis durch Glück erwerben können — aber er schuf das Glück, indem er aktiv nach Sprechgelegenheiten suchte, dann die Disziplin entwickelte, sie systematisch zu nutzen.
Bewusste Praxis & Karriere-Kapital
Hammings 30-Jahr-Talk war ein Fall von bewusster Praxis, angewendet auf intellektuelle Arbeit: eine systematische, wiederholte Übung mit Feedback-Zyklen, die kumulative Fähigkeit über Zeit aufbaute.
Die Struktur: (1) verpflichte dich auf ein Thema an der Grenze deines Wissens; (2) halte einen Talk, der dich zwingt, ihn zu kennen; (3) erhalte Feedback (Publikumsreaktion, Fragen, die du nicht beantworten konntest); (4) aktualisiere den Talk; (5) wiederhole.
Jeder Zyklus addiert sich zu einem Modell. Jede Aktualisierung erzwingt Kontakt mit neuen Daten. Jede Publikumsfrage offenbart eine Lücke. Über 30 Jahre wird das Modell tief.
Hardware, Software & Anwendungen verbinden
Kapitel 3, 4, & 5 bilden eine Progression. Hamming baute das Argument über drei Vorlesungen auf:
Kapitel 3 (Hardware): physische Grenzen schränken ein, was Maschinen tun können. Drei Gesetze — Molekülgröße, Lichtgeschwindigkeit, Wärme — setzen Decken, die keine Technik entfernen kann.
Kapitel 4 (Software): menschliche Grenzen schränken ein, was Programme tun können. Sprachen, die für logische Eleganz entworfen wurden, scheitern; Sprachen, die für menschliche Psychologie entworfen wurden, überdauern. Abstraktionsschichten akkumulieren, jede löst den Schmerz der vorherigen Schicht.
Kapitel 5 (Anwendungen): wirtschaftliche & organisatorische Grenzen schränken ein, was gebaut wird. Technologie folgt S-Kurven. Gemeinsamer änderbarer Zustand bricht Optimierung. Mustererkennung bleibt eine offene Herausforderung.
Das vereinigende Thema: Grenzen verschieben sich. Der Praktiker, der das Modell der aktuellen bindenden Einschränkung aktualisiert — und die Fähigkeiten entsprechend positioniert — outperformt konsistent denjenigen, der für die Einschränkungen von gestern optimiert.
Hammings Karrierelektion aus dem 30-Jahr-Talk: denselben Talk wiederholt zu halten zwang ihn, Trends zu verstehen. Der Mechanismus war nicht der Talk selbst, sondern der Vorbereitungszyklus: Was änderte sich, in welche Richtung, und warum? Wiederholte Vorbereitung baute ein Modell, das einfaches Lesen nicht konnte.
Was ist die aktuelle bindende Einschränkung?
In Hammings Rahmen hat jede Ära eine bindende Einschränkung: die Grenze, die, wenn entfernt, Fortschritt am meisten beschleunigen würde. In den 1940ern: Hardware-Geschwindigkeit. In den 1970ern: Software-Fähigkeit. In den 1990ern: Wirtschaft & organisatorische Kapazität.