Ideen & Einblicke

AI-First-Entwicklung, Coding-Leitplanken und die Architektur der Entsorgbarkeit erkunden.

Texteditoren erlauben das Schreiben von ungültigem Code. Tree-Editoren würden das nicht tun.

Jeder Compiler sieht deinen Code als Baum, aber dein Editor lässt dich rohen Text bearbeiten. So sieht strukturiertes Editieren tatsächlich aus, warum es sich nicht durchgesetzt hat und wie du seine Vorteile nutzen kannst, ohne Tools zu wechseln.

Jede Programmiersprache hat eine formale Grammatik. Dein Compiler liest sie, baut einen Parse-Tree auf und verwirft alles, was nicht passt. Dein Editor…

Donald Knuth wollte, dass Programme wie Literatur gelesen werden. Der Compiler hatte andere Pläne.

Literate Programming versprach, dass Code erst für Menschen und dann für Maschinen geschrieben werden sollte. Vier Jahrzehnte später schreibt fast niemand so. Hier ist, warum die eleganteste Idee der Software-Dokumentation die Art und Weise, wie wir arbeiten, nicht verändern konnte.

1984 veröffentlichte Donald Knuth einen Aufsatz, der eine radikale Umkehrung vorschlug. Programme sollten nicht für Compiler geschrieben und für Menschen…

Den Bug zu beheben ist der einfache Teil. Herauszufinden, warum er existiert, ist das, was zählt.

Die meisten Teams beheben Defekte und machen weiter. Dieselben Defekte kommen zurück. So führen Sie Kausalanalyse innerhalb einer Fagan-Inspection durch, damit Sie denselben Bug nicht zweimal schreiben.

Jedes Team hat diesen einen Defekt, der immer wieder zurückkommt. Ein Off-by-one in der Paginierung. Ein fehlender Null-Check im Auth-Middleware. Ein Race…

Pull-Request-Reviews finden 15–30 % der Defekte. Die Daten sagen das seit 50 Jahren.

Mehrere Studien bei IBM, AT&T, HP und Microsoft bestätigen, dass informelle Code-Reviews etwa ein Viertel der Defekte finden. Hier ist, was die Daten tatsächlich sagen, warum die Zahl so niedrig ist und wie man das behebt.

Informelle Code-Reviews finden zwischen 15 und 30 Prozent der Defekte, die im überprüften Code vorhanden sind. Das ist keine Meinung. Es ist ein Befund, der…

Eine generische Checkliste findet nichts. Eine strukturierte findet 60 % der Defekte.

Die meisten Review-Checklisten sind kopiert-eingefügte Listen guter Absichten. Eine im Stil einer Fagan inspection strukturierte Checkliste wird aus tatsächlichen Defektdaten erstellt, auf bestimmte Artefakttypen zugeschnitten und während der individuellen Vorbereitung verwendet. So baut man eine, die funktioniert.

Wenn dein Team eine Code-Review-Checkliste hat, gibt es eine gute Chance, dass sie auf einer Wiki-Seite existiert, die niemand öffnet. Sie sagt wahrscheinlich…

Ein LLM kann Ihren Code vorab prüfen. Es kann aber nicht das Meeting leiten.

Fagan-Inspektionen benötigen vier bis sechs Personen und zwei Stunden, um 250 Zeilen zu reviewen. Ein LLM kann diese Kosten senken, indem es Vorbereitung und Checklisten-Überwachung übernimmt, aber es kann die menschlichen Rollen nicht ersetzen, die die teuersten Defekte finden.

Eine vollständige Fagan-Inspektion benötigt einen Moderator, einen Vorleser, zwei bis vier Inspektoren und den Autor. Das Team verbringt zwei Stunden damit,…

Fagan Inspections fanden 90 % der Defekte vor dem Testing. Dann haben wir aufgehört, sie durchzuführen.

Michael Fagans strukturierter Review-Prozess bei IBM erfasste fast alle Defekte, bevor sie den Compiler erreichten. Er verschlang aber auch 15–20 % des Gesamtprojektaufwands. Hier ist, warum die effektivste Review-Methode in der Softwaregeschichte verschwand und was Teams tatsächlich vermissen.

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…

Dein bester Reviewer übersieht die meisten Defekte. Fagan hat es 1976 bei IBM gemessen.

Selbst Senior Engineers finden nur einen Bruchteil der Defekte in unstrukturiertem Review. Michael Fagans IBM-Forschung zeigte warum, und er baute einen strukturierten Inspection-Prozess, um das zu beheben.

Zwei Senior Engineers reviewen denselben Pull Request. Einer markiert einen fehlenden Null Check. Der andere entdeckt einen Race Condition im Cleanup-Path.…

Die meisten Code Reviews finden 20 % der Defekte. Fagan Inspections finden 90 %.

Informelles Code Review findet 15–30 % der Defekte. Fagan Inspections, ein strukturierter 50 Jahre alter Prozess, berichten konstant von 60–90 % Entfernungsraten. So funktionieren sie, warum Teams sie vermeiden, und wie man eine leichtgewichtige Version durchführt.

Die meisten Code Reviews finden zwischen 15 und 30 Prozent der Defekte, die sie finden sollten. Das ist keine Vermutung. IBM hat das in den 1970ern gemessen,…

AutoVerus verwandelt 40 Stunden Proof-Writing in 3 LLM-Calls. Der Trick ist, zu wissen, wann man aufgibt.

AutoVerus nutzt ein Netzwerk von LLM-Agents, um Verus-Correctness-Proofs für Rust-Code zu generieren und über 90% der Proof-Obligations durch eine Generate-Repair-Discharge-Schleife zu automatisieren, die vom Feedback des SMT-Solvers getrieben wird.

Der schwierigste Teil der formalen Verifikation war nie der Verifier. Es ist das Schreiben des Proofs. Gib einem erfahrenen Rust-Engineer Verus, den…