Der effektivste Qualitätsprozess, den niemand nutzt

1976 veröffentlichte Michael Fagan einen Artikel im IBM Systems Journal, der einen Review-Prozess beschrieb, der so effektiv war, dass er zum Goldstandard für Softwarequalität wurde. Fagan Inspections fingen 60 bis 90 Prozent aller Defekte, bevor ein einziger Test lief. Eine 2002er-NASA-Studie ergab, dass jede im Review verbrachte Stunde durchschnittlich 33 Stunden Wartungsarbeit später verhinderte.

Nach jedem messbaren Standard war das der beste Review-Prozess, den die Softwareentwicklung je hervorgebracht hat.

Fast niemand nutzt ihn heute.

Die Frage ist nicht, ob Fagan Inspections funktionierten. Sie funktionierten beinahe zu gut. Die Frage ist, warum ein Prozess mit dieser Erfolgsbilanz aus der Mainstream-Entwicklung verschwand und ob wir etwas Wichtiges verloren haben, als wir ihn ersetzten.

Wie Fagan Inspections tatsächlich aussahen

Fagan hat nicht das Code Review erfunden. Er hat ein spezifisches, hochstrukturiertes Ritual zum Finden von Defekten erfunden.

Der Prozess hatte sechs starre Phasen:

  1. Planning: Ein Moderator wählte Teilnehmer aus und verifizierte, dass das Material die Entry Criteria erfüllte.
  2. Overview: Der Autor erklärte den Hintergrund. Das diente der Kontextschaffung, nicht dem Review.
  3. Preparation: Jeder Teilnehmer prüfte das Material unabhängig, mit etwa 150 Zeilen pro Stunde, und erstellte eine persönliche Liste vermuteter Defekte.
  4. Inspection Meeting: Das Team kam für maximal zwei Stunden zusammen. Ein Reader trug die Logik laut vor. Ein Recorder protokollierte Defekte. Der Moderator hielt das Meeting darauf fokussiert, Defekte zu finden, nicht sie zu lösen.
  5. Rework: Der Autor behebung jeden protokollierten Defekt.
  6. Follow-up: Der Moderator verifizierte, dass Korrekturen vorgenommen wurden und keine neuen Defekte eingeführt wurden.

Die Rollen waren spezifisch und nicht überlappend. Der Moderator führte den Prozess, war aber nicht die technische Autorität. Der Reader trug den Code vor, verteidigte ihn aber nicht. Der Autor war anwesend, durfte aber während des Meetings seine Absicht nicht erklären. Der Zweck war nicht Kollaboration. Es war kalte, systematische Defektfindung.

Das ist der Teil, der es funktionieren ließ. Die Sozialdynamik normaler Engineering-Meetings wurde herauskonstruiert.

Warum die Zahlen so gut waren

Die Defektfindungsrate war kein Zufall. Sie resultierte aus einigen bewussten Designentscheidungen.

Die unabhängige Preparation bedeutete, dass sechs Personen denselben Code isoliert prüften, bevor eine Gruppendiskussion sie beeinflussen konnte. Die Überschneidung ihrer Listen zeigte, wie offensichtlich ein Defekt war. Die Einträge, die nur eine Person fand, waren oft die wertvollsten.

Die harte Zwei-Stunden-Grenze verhinderte, dass Müdigkeit das Urteilsvermögen zerstörte. Fagan wusste, dass die Inspektionseffektivität nach etwa zwei Stunden dramatisch abfällt. Die Rate von 150 Zeilen pro Stunde war ebenfalls bewusst gewählt. Wenn man schneller geht, beginnt man zu sehen, was man erwartet, statt was tatsächlich da ist.

Die No-Solutions-Regel hielt Meetings fokussiert. Nichts zerstört eine Inspektion schneller als ein Raum voller Engineers, die eine Lösung für einen Defekt entwerfen, den sie noch nicht vollständig charakterisiert haben.

Diese Constraints waren keine bürokratische Overhead. Sie waren der Mechanismus. Entfernt man sie, erhält man etwas Freundlicheres, aber weniger Effektives.

Was Fagan Inspections getötet hat

Wenn der Prozess so effektiv war, warum ist er verschwunden?

Die kurze Antwort ist, dass er genau auf die Weise teuer war, die die moderne Softwareentwicklung nicht toleriert.

Eine einzelne Fagan Inspection verschlang 15 bis 20 Prozent des Aufwands, der für das Schreiben des reviewed Codes aufgewendet wurde. In einem dokumentierten Fall erforderten 348 Zeilen 27,3 Personenstunden Inspektion. Dieses Verhältnis ist unvorstellbar, wenn Teams mehrmals täglich ausliefern.

Allein das Scheduling war ein Vollzeitjob. Man brauchte fünf oder sechs Personen zwei Stunden lang im selben Raum, plus Preparation, plus Follow-up. In einer großen Organisation konnte es Tage dauern, einen zwei Stunden langen Slot zu finden, in dem Moderator, Reader, zwei Reviewer, Recorder und Autor alle verfügbar waren.

Die starre Rollenstruktur skalierte ebenfalls nicht. Fagan Inspections gingen von einem stabilen Team aus, das genug Personen hatte, um alle Rollen zu füllen. In einem Startup könnte ein Fünf-Personen-Team niemanden haben, der als dedizierter Moderator dient, ohne die Velocity zu zerstören.

Der größte Faktor war kulturell. Fagan Inspections waren bewusst unbequem. Der Autor saß schweigend da, während Kollegen seinen Code vorlasen und seine Defekte protokollierten. Es gab keinen Raum für „das ist nur ein erster Entwurf“. Der Prozess ging davon aus, dass Defekte teuer sind und soziale Reibung billig. Modernes Engineering basiert auf der gegenteiligen Annahme.

Womit wir es ersetzt haben

Die Industrie hat strukturiertes Review nicht aufgegeben. Sie hat es durch pull requests ersetzt.

Pull-Request-Review ist asynchron, mit wenig Zeremonie, und direkt in den Development Workflow eingebettet. Ein Reviewer kann sich einen diff zwischen Meetings ansehen, auf seinem Handy oder während er auf CI wartet. Es gibt keine zugewiesenen Rollen. Autor und Reviewer sind oft dieselbe Person, die nur noch eine Approval braucht, um zu mergen.

Das ist eine massive Verbesserung in Sachen Zugänglichkeit, Geschwindigkeit und Developer Experience. Es ist auch ein massiver Rückschritt in der Defektfindung.

Mehrere Studien fanden, dass informelles Review etwa die Hälfte der Defekte findet, die strukturierte Inspektion findet. Ein 2009er-Experiment von Basili und anderen verglich Fagan-style Inspection mit lightweight Review und fand, dass der leichtere Prozess signifikant weniger Defekte im selben Material fand.

Das Problem ist nicht, dass Reviewer faul sind. Der Prozess ist nicht darauf ausgelegt, Defekte zu finden. Er ist darauf ausgelegt, Leuten zu erlauben, Code auszuliefern, auf den ein zweites Paar Augen geschaut hat, was nicht dasselbe ist.

Was wir tatsächlich verloren haben

Pull-Request-Review optimiert für Durchsatz. Fagan Inspection optimierte für Gründlichkeit. Das sind grundverschiedene Ziele, und keines ist falsch. Der Fehler ist anzunehmen, dass der leichtere Prozess eine strenge Obermenge des schwereren ist.

Hier ist, was verschwand:

Independent preparation. Bei einem pull request sieht der Reviewer den diff kalt. Er hat keine Stunde damit verbracht, den umgebenden Kontext zu lesen, Datenflüsse zu verfolgen und ein mentales Modell aufzubauen. Er reagiert auf eine Benachrichtigung. Die Tiefe der Prüfung ist nicht vergleichbar.

Die Reader-Rolle. Wenn jemand Code laut vorliest, zwingt er die Gruppe, in einem Tempo voranzugehen, das der langsamsten Person folgen kann. Es legt Annahmen offen, die stilles Lesen verbirgt. Ein diff auf einem Bildschirm lässt die Augen die langweiligen Teile überspringen. Ein Reader überspringt nicht.

Defect-only focus. Pull-Request-Kommentare driften in Stil- und Architekturmeinungen ab. Diese sind wertvoll, aber sie sind keine Defektfindung. Jede Minute, die mit der Debatte über Einrückung verbracht wird, ist eine Minute, die nicht damit verbracht wird, einen null dereference zu finden.

Messbare Prozessdaten. Fagan Inspections produzierten harte Zahlen: Defekte pro Stunde, Preparation Time, Rework Time, Defect Density pro Modul. Moderne Review-Tools zählen Kommentare und Approvals, die fast nichts über Review-Qualität aussagen.

Ein praktikabler Mittelweg

Du wirst in einer modernen Continuous-Deployment-Umgebung keine vollständigen Fagan Inspections durchführen. Aber du kannst dir die Teile leihen, die wichtig sind.

Die wichtigste übertragbare Idee ist strukturierte independent preparation. Bevor ein tiefgreifendes async Review, verlange von Reviewern, dass sie allein Zeit mit dem Material verbringen. Kein schneller Überflug. Echte Preparation.

Statt eines generischen „LGTM“, erzwinge eine lightweight Checkliste, die die Disziplin nachahmt, die Fagan in Rollen und Regeln eingebaut hat:

from dataclasses import dataclass, field
from typing import List, Optional
from enum import Enum

class DefectSeverity(Enum):
    MINOR = "minor"
    MAJOR = "major"
    CRITICAL = "critical"

@dataclass
class ReviewEntry:
    line_number: Optional[int]
    category: str
    severity: DefectSeverity
    description: str

@dataclass
class InspectionReport:
    reviewer: str
    prep_time_minutes: int
    entries: List[ReviewEntry] = field(default_factory=list)

    def defect_count(self) -> int:
        return len(self.entries)

def run_inspection_checklist(
    code: str,
    reviewer: str,
    prep_time_minutes: int
) -> InspectionReport:
    """Structured prep produces structured output.

    Mimics the Fagan prep phase: reviewer spends focused
    time with the material, then logs findings against a
    consistent taxonomy instead of ad hoc comments.
    """
    report = InspectionReport(
        reviewer=reviewer,
        prep_time_minutes=prep_time_minutes
    )

    # Example: check for missing null handling
    if "->" in code and "null" not in code.lower():
        report.entries.append(ReviewEntry(
            line_number=None,
            category="null-safety",
            severity=DefectSeverity.MAJOR,
            description="No explicit null handling in pointer function"
        ))

    return report

Das ist keine Fagan Inspection. Es ist ein Weg, eine ihrer wichtigsten Eigenschaften wiederzugewinnen: Review-Output sollte strukturiert, messbar und auf Defect Categories statt auf Meinungen fokussiert sein.

Eine weitere übertragbare Idee ist das time-boxed deep review. Wähle ein kritisches Modul pro Sprint. Plane ein 90-minütiges fokussiertes Review mit independent preparation. Protokolliere nur Defekte. Keine Lösungen, keine Stildebatten, keine Designargumente.

Die Kosten sind real. Aber wenn das NASA-Verhältnis auch nur annähernd hält, spart eine fokussierte Stunde jetzt Dutzende Stunden Debugging später.

Die unbequeme Wahrheit

Fagan Inspections sind nicht gescheitert. Sie wurden abgelehnt, weil die Rigorosität, die sie erforderten, inkompatibel mit der Geschwindigkeit war, die die Industrie priorisierte.

Dieser Kompromiss ergab für viele Softwareprojekte Sinn. Ein Tippfehler auf einem landing page button braucht keine fünfköpfige formale Inspektion. Aber die Kultur, die Fagan Inspections ersetzt hat, behandelt allen Code gleich, und dort versteckt sich die Kosten.

Die teuersten Defekte befinden sich in Code, der korrekt aussieht, Tests besteht und in der Produktion auf Weisen versagt, die echtes Geld kosten. Das ist genau der Code, der am meisten von einem Prozess profitiert, der darauf ausgelegt ist, Defekte zu finden, statt von einem Prozess, der darauf ausgelegt ist, diffs zu approven.

Pull-Request-Review ist hier, um zu bleiben, und das ist in Ordnung. Aber so zu tun, als wäre er ein Ersatz für strukturierte Inspektion, ist nicht in Ordnung. Es ist ein anderes Werkzeug für einen anderen Job, und Teams, die nur eines von beiden besitzen, werden weiterhin teure Bugs finden, die ein besserer Prozess vor dem Shipping gefunden hätte.

FAQ

Was ist eine Fagan Inspection?

Ein strukturierter, mehrphasiger Review-Prozess zum Finden von Defekten in Software-Artefakten, entwickelt von Michael Fagan bei IBM in den 1970ern. Er umfasst sechs Phasen (Planning, Overview, Preparation, Inspection Meeting, Rework, Follow-up) mit spezifischen Rollen für Teilnehmer. Das Meeting konzentriert sich ausschließlich auf das Protokollieren von Defekten, nicht auf deren Lösung.

Wie effektiv waren Fagan Inspections?

IBM berichtete Defect-Removal-Raten von über 90 Prozent. Eine 2002er-NASA-Studie fand, dass jede Stunde Inspektion durchschnittlich 33 Stunden Wartung verhinderte. Unabhängige Studien fanden konsistent, dass strukturierte Inspektion etwa doppelt so viele Defekte findet wie informelles Review.

Warum haben Teams aufgehört, Fagan Inspections zu nutzen?

Der Prozess verschlang 15 bis 20 Prozent des Gesamtprojektaufwands, erforderte schwieriges Scheduling mehrerer Teilnehmer und war kulturell starr. Als Softwareteams zu schnelleren Release-Zyklen wechselten, wurde der Overhead unhaltbar. Pull-Request-Review ersetzte es als Default, weil es schneller und einfacher in normale Workflows zu integrieren ist, auch wenn es weniger Defekte findet.

Können moderne Teams noch von Fagan Inspections profitieren?

Nicht in der ursprünglichen Form. Der volle sechsphasige Prozess mit zugewiesenen Rollen passt nicht zu Continuous Deployment. Aber die Kernideen – independent preparation, time-boxed focused review, structured defect logging und die Trennung von Defektfindung und Solution Design – können adaptiert werden. Teams, die diese selektiv auf kritischen Code anwenden, erhalten einen Großteil des Nutzens ohne den Overhead.