Hauptgedanke

Bei einer mit einem Assistenten entwickelten Anwendung zu fragen „Funktioniert es?“, sagt nichts darüber, ob man sie im Griff hat: Bildschirme, die antworten, eine Datenbank, die existiert, und eine API, die läuft, vertragen sich bestens mit Hunderten technischer Entscheidungen, die niemand erklären kann. Die Frage, die den Unterschied macht, ist eine andere: Könnte man dieses System anderswo neu bauen, in einer anderen Technologie?

Darauf mit Ja zu antworten setzt voraus, dass man weiß, wo die Verträge zwischen den APIs liegen, wo die Fachregeln leben und welche Tests das erwartete Verhalten beschreiben statt der aktuellen Implementierung. Diese drei Orientierungspunkte gewinnt man nicht im Nachhinein: Man muss sie während des Baus durchsetzen — die Verträge einfordern, erst die Testfälle und dann die Testpyramide erstellen lassen, bevor entwickelt wird, sich weigern, die Fachlogik über die Endpunkte zu verstreuen, auch ohne bis zu einem vollständigen DDD-Vorgehen zu gehen, das das Projekt nicht rechtfertigt.

Der Neuaufbau muss gar nicht stattfinden. Er dient als Kontrollfrage, und die Antwort misst, was das Team über das System sagen kann, statt dessen, was das System anzeigt.

Warum das wichtig ist

Das liefert ein belastbares Qualitätskriterium dort, wo die Auslieferungsgeschwindigkeit nichts mehr aussagt. Eine Demo, die funktioniert, gelingt unabhängig davon, wie es um das Verständnis steht; „Könnte ich es neu aufbauen?“ scheitert genau dann, wenn es fehlt.

Es macht das Verständnis außerdem zu einer Anforderung an den Entwurf statt zu einer persönlichen Tugend: Erkennbare Trennlinien machen es möglich, und über sie wird entschieden, während man baut.

Nuancen und Grenzen

Niemand baut neu, nur um zu prüfen, ob er es gekonnt hätte. Das Kriterium bleibt also eine Frage der Selbstprüfung und ist der Nachsicht dessen ausgeliefert, der sie beantwortet — ein System kann dem, der es gesteuert hat, rekonstruierbar erscheinen und es für niemanden sonst sein.

Und es sagt nichts über den Wert des Systems: Man kann eine Anwendung, die niemandem nützt oder deren Architektur mittelmäßig ist, durchaus identisch nachbauen können.

Offene Fragen

• Welche kurze Probe — ein Modul von jemand anderem übernehmen lassen, eine Komponente neu schreiben, ohne das Bestehende vor Augen zu haben — würde diesem Kriterium eine Überprüfung geben, die nicht von der Selbsteinschätzung abhängt?