Am 22. Juni 2026 veröffentlichte Martin Tournoij (arp242) einen kurzen Artikel, dessen Titel nur einen Buchstaben vom klassischen Prinzip abwich – aus Fence wurde Finger. Hinter diesem Wortspiel verbarg sich ein reales Software-Engineering-Disaster. Er wurde angeheuert, um eine 13 Jahre alte Codebasis zu übernehmen, aus der vor ihm alle gegangen waren. Der git log enthielt insgesamt 295 Commit-Beschreibungen; nach Abzug von Dependabot-Autocommits und »fix typo« blieben 167 übrig – im Schnitt eine pro Monat. Keine Designdokumentation, fast keine Kommentare im Code. Zurückgelassene, nie vollendete Refactorings, Überreste gelöschter Funktionen und Features, die geschrieben, aber von keiner Seite je referenziert wurden.
Tournoij nannte das Chestertons Mittelfinger. »Ja, wir haben all diese seltsamen Dinge getan, und wir haben nicht vor, irgendjemandem zu sagen, warum. Haha, fick dich.«
Chestertons Zaun – dieses Prinzip stammt aus G.K. Chestertons Buch »The Thing« von 1929. Die Parabel ist simpel: Ein Reformer sieht mitten auf einem Weg einen Zaun, hält ihn für nutzlos und will ihn abreißen. Chesterton sagt: Halt, reiß ihn nicht gleich ein – finde erst heraus, warum er damals gebaut wurde. Vielleicht siehst du den Grund noch nicht, aber der Grund hat einmal existiert. Dieses Prinzip wird in der Software-Engineering-Community immer wieder zitiert, weil es präzise ein häufiges Unfallszenario trifft: Jemand löscht Code, der »nutzlos aussieht«, und Monate später geht die Produktion down – weil jener Code einen Boundary Case behandelte, der nur alle drei Jahre auftritt. Niemand weiß, warum er dort war, denn derjenige, der ihn schrieb, ist seit zwei Jahren weg.
arp242 änderte Fence zu Finger nicht aus bloßer Spielerei. Das Problem in Tournoijs Codebasis war nicht, dass der Code schlecht geschrieben war – schlechter Code gibt es überall. Das Problem war, dass niemand irgendeine Aufzeichnung über das »Warum« hinterlassen hatte. 13 Jahre kumulierter Entscheidungen, aller Abwägungen, aller historischen Randbedingungen, aller Fallgruben – alles verdampft. Der Übernehmende steht nicht vor »einem Zaun« – ein Zaun ist wenigstens ein sichtbares physisches Objekt, das suggeriert: »Hier hat einmal jemand eine Entscheidung getroffen.« Er steht vor einem vollständigen Informationsvakuum. Das ist weit schlimmer als ein Zaun. Der Zaun ist ein stummer Hinweis; der Mittelfinger ist stummer Hohn.
Dieser Unterschied berührt den Kernwert von Code-Kommentaren. Der Code selbst sagt bereits, »was getan wurde« – solange die Sprache nicht absichtlich obfuskiert ist, ist die Logik lesbar. Aber Code kann niemals sagen, »warum Option A statt Option B gewählt wurde«. Dieser merkwürdige Workaround existiert wegen eines Bugs in einer bestimmten Bibliotheksversion; jener scheinbar überflüssige Null-Check geht auf einen P0-Vorfall an einem Freitagnachmittag im Jahr 2019 zurück; diese seltsame Sortierlogik rührt daher, dass ein nachgelagertes System eine feste Abhängigkeit von der Reihenfolge hat, die selbst ein historischer Fehler ist. Wenn diese Informationen nicht in Kommentaren oder Commit-Beschreibungen stehen, sind sie für immer verloren. Tournoijs Frage ist direkt: Diese Dinge zu schreiben ist keine optionale Zusatzarbeit – es ist Teil der Entwicklungsarbeit. Es muss nicht perfekt sein, die Englischkenntnisse müssen nicht gut sein, und es ist in Ordnung, Details zu vergessen – aber irgendetwas muss da sein. Gar nichts zu hinterlassen, ist der Mittelfinger an alle, die nach dir kommen.
Im Lobsters-Forum brachte ChrisDenton (18 Stimmen) das Thema auf die Organisationsebene. Er wies auf ein subtileres Dilemma hin: Manchmal weiß zum fraglichen Zeitpunkt niemand, welche Informationen später wichtig sein werden. Wenn die Diskussionen um eine Entscheidung nicht dokumentiert werden – egal ob in E-Mails, Chats oder Issues –, ist die spätere »digitale Archäologie« fast unmöglich. Und wenn eine Organisation Entwickler als austauschbare Teile betrachtet, wird diese Verletzlichkeit maximal verstärkt. Niemand bleibt lange genug, niemand sammelt ein intuitives Verständnis des Gesamtsystems, dieselben Fehler werden immer wieder gemacht, das ständige Neuerfinden von Rädern wird zur Normalität. ChrisDentons Formulierung ist zurückhaltend, aber die Schlussfolgerung ist scharf: Organisationen, die Entwickler als austauschbare Teile betrachten, sind die verletzlichsten Organisationen.
david_chisnall (8 Stimmen) fügte aus der Perspektive des Code-Reviews einen weiteren Punkt hinzu. Er sagt, der größte Wert des Code-Reviews sei, dass es dich zwingt, nicht offensichtliche Entscheidungen mit Kommentaren zu versehen – das Finden von Bugs sei nur ein Nebenprodukt. Der größte Wert ist: »Eine zweite Person zwingt dich dazu, nicht offensichtliche Entscheidungen zu kommentieren.« Er selbst schreibt Kommentare für das, was ihm nicht offensichtlich erscheint. Der Reviewer fragt nach dem, was ihm nicht offensichtlich erscheint. Nach zwei Runden sind die Kommentare so, dass sie das abdecken, was zwei Personen jeweils für erklärungsbedürftig hielten. Wenn später jemand diesen Code liest, ist die Wahrscheinlichkeit des Verstehens nicht mehr Null. Das Schöne an diesem Mechanismus ist, dass er nicht auf das Bewusstsein des Autors angewiesen ist – er bettet die Wissensbewahrung in einen zwingend durchzuführenden Prozess ein.
Aber sollte wirklich jeder Zaun stehen bleiben? Die Frage hat auch eine Kehrseite. Steph Tulkens schrieb »Chesterton’s Gap« – der Zaun sei noch gar nicht gebaut, also bau ihn erst einmal. Übermäßige Vorsicht ist ebenfalls schädlich: Jedes Team kennt diesen Legacy-Code, den niemand anzurühren wagt, um den herum sich die Logik bereits dreimal geändert hat, und der das ursprüngliche Problem vielleicht längst nicht mehr adressiert – aber weil »niemand weiß, warum er damals geschrieben wurde«, bleibt er für immer stehen. Technische Schulden entstehen nicht nur durch rücksichtsloses Ändern von Code; auch das Nicht-Ändern aus Angst erzeugt technische Schulden. Wann man einen Zaun einreißen und wann man ihn stehen lassen sollte – dafür gibt es keinen Algorithmus. Das Urteilsvermögen kann nur aus einem ausreichend tiefen Verständnis des Systems erwachsen – was genau zu ChrisDentons These zurückführt: Organisationen, die Entwickler als austauschbare Teile betrachten, können nicht einmal dieses Urteilsvermögen entwickeln.
Hier ist ein vereinfachter Entscheidungsrahmen in Form einer Fragenliste:
| Dimension | Tendenz zum Erhalten | Tendenz zum Entfernen |
|---|---|---|
| Verfügbarkeit von Kontext | Ursprungsteam komplett weg, keine Doku, keine Kommentare | Entscheider noch da, kann direkt befragt werden |
| Auswirkungsbereich der Änderung | Betrifft kritische Geschäftspfade, Fehlerfolgen schwerwiegend | Isoliertes Modul mit vollständiger Testabdeckung |
| Klarheit der Code-Intention | Kommentar erklärt »Warum«, Logik konsistent | Kommentar erklärt »Was« und stimmt nicht mit Code überein |
| Auslösefrequenz | Behandelt seltene, aber folgenschwere Randbedingungen | Code erwiesenermaßen nie ausgeführt |
| Ersatzkosten | Neuschreiben erfordert Wiederentdeckung aller Randbedingungen | Klare Spezifikation als Vorlage für Neuschreibung vorhanden |
Diese Tabelle löst kein Problem. Sie erinnert nur daran: Zu entscheiden, ob ein Zaun abgerissen werden soll, erfordert mehr Informationen als das Abreißen selbst.
Tournoijs Artikel erhielt auf Lobsters 82 Stimmen – nicht, weil er etwas Neues gesagt hätte. Chestertons Zaun wird in der Softwareentwicklung seit einem Jahrzehnt diskutiert. Die Resonanz rührte von dem Gefühl her, das er benannte – schlechten Code zu schreiben ist nicht unbedingt böswillig, aber zu gehen, ohne eine einzige Erklärung zu hinterlassen, ist Verachtung gegenüber allen, die nach dir kommen. Jeder Entwickler, der um drei Uhr morgens von »diesem unverständlichen Legacy-Code« geweckt wurde, erkennt diesen Mittelfinger wieder. Die Lösung erfordert nicht noch mehr Prozessvorschriften, sondern nur, die Commit-Beschreibung als Teil des auszuliefernden Artefakts zu betrachten. Die 167 Zeilen in 13 Jahren – allein diese Zahl ist das überzeugendste Argument.