Was macht ein System überlebensfähig? (7/8)
TCP/IP, Unix-Pipes, SQL und Postgres überleben seit Jahrzehnten, weil sie textlich, klar begrenzt, rückwärtskompatibel, semantisch bescheiden und institutionell eingebettet sind. Keine dieser Eigenschaften ist clever — alle sind demütig, und genau deshalb wirken sie. Zeit ist die Ressource, über die wir im Design fast nie ehrlich nachdenken.
Einleitung
TCP/IP wurde 1981 standardisiert.
Unix-Pipes gibt es seit den frühen siebziger Jahren.
SQL stammt aus derselben Zeit.
Postgres ist seit den späten achtziger Jahren dabei.
Jedes dieser Systeme hat die Erwartungen von 1980 überlebt.
Die achtziger, die neunziger, die Cloud, Mobile, die KI-Welle.
Und wird mit hoher Wahrscheinlichkeit auch die nächste Welle überstehen.
Was haben sie gemeinsam?
Die Eigenschaften
Meine Beobachtung nach zwanzig Jahren mit verschiedensten Systemen:
Sie teilen einige wenige Eigenschaften.
Keine davon ist technisch clever.
Alle sind demütig.
Und sie wirken, weil sie demütig sind — nicht obwohl.
Textlich, wo möglich
Unix-Pipes arbeiten mit Text.
CSV, JSON — Text.
SQL — Text.
Das hat einen Grund.
- Text lässt sich lesen, ohne das Tool zu haben, das ihn geschrieben hat.
- Text lässt sich in jeder Sprache verarbeiten, die es gibt und noch geben wird.
- Binärformate sind schneller, aber sie setzen voraus, dass der Leser die Version des Schreibers kennt.
Text tut das nicht.
Klare Grenzen
Eine Unix-Pipe ist ein Bytestrom zwischen zwei Prozessen.
Nicht mehr.
- Kein geteilter Speicher
- Kein impliziter Zustand
- Keine Callbacks
TCP stellt Bytes zu.
Was darin steht, ist nicht sein Problem.
SQL hat eine Tabellenform.
Die Formate verschweigen nichts, was in ihnen nicht steht.
Das klingt trivial.
Es ist die schwerste Eigenschaft in Software überhaupt.
Rückwärtskompatibilität als Wert
Postgres bricht Clients ungern.
Features werden über mehrere Versionen entfernt, mit Deprecation-Warnungen.
TCP hat seit Jahrzehnten dieselben Kernsemantiken.
Das ist kein Zufall.
Es ist eine Haltung, die entschieden wurde, als diese Systeme jung waren.
Und eingehalten wurde, als sie es nicht mehr waren.
Semantisch arm
SQL ist als Sprache nicht elegant.
Es hat Inkonsistenzen, Lücken, anachronistische Syntax.
Aber es ist spezifiziert genug,
dass Dutzende Implementierungen sich auf gemeinsames Verhalten einigen können.
Eine reichere, elegantere Sprache wäre schwerer zu standardisieren.
Also fragmentierter.
Armut an Semantik ist in Standards oft eine Tugend.
Institutionell eingebettet
Für TCP/IP gibt es die IETF.
Für SQL gibt es ANSI.
Für Unix gibt es POSIX.
Jedes dieser Systeme hat ein Dokument, auf das man sich berufen kann.
Und eine Community, die es fortschreibt.
Das ist der Unterschied zu vielen Open-Source-Projekten, in denen die Spezifikation das Repository ist.
Institutionelle Einbettung verlagert Wissen aus dem einzelnen Kopf in die Organisation.
Der Moment im Designreview
In fast jedem Designreview, in dem ich gesessen habe, gab es einen Moment:
Jemand sagt:
„Wir können doch hier einfach ein eigenes Binärformat definieren, das ist viel effizienter.”
Der Satz stimmt.
Er stimmt in einer Messung.
Und er fügt dem System eine Abhängigkeit hinzu,
die in zehn Jahren zur Last wird,
wenn jemand das Format lesen will, der das System nicht kennt.
Der Moment, in dem man sich für Text entscheidet, sieht langweilig aus.
Er ist die einzige Entscheidung, die in zwanzig Jahren nicht bereut wird.
Zentrale Beobachtung
Überlebensfähigkeit ist keine Eigenschaft, die man einem System hinzufügt.
Sie ist die Zusammenfassung vieler kleiner Entscheidungen,
die für sich genommen unauffällig wirken.
Zeit ist die Ressource, über die wir im Design fast nie ehrlich nachdenken.
Abschlussgedanke
Wer Systeme bauen will, die bleiben, sollte aufhören, clever zu sein.
Und anfangen, demütig zu sein.
Das ist kein moralischer Ratschlag.
Es ist ein Designprinzip.
