Früher hieß es: Die Wahrheit liegt im Code. Spec-Driven-Development dreht diesen Satz um. Die Spezifikation wird fortgeschrieben, sie beschreibt den Stand der Software, und der Code ist nur noch das, was daraus erzeugt wird. Ich habe mir das genau angesehen und es für meine Arbeit wieder verworfen.

Ich habe dazu recherchiert und mit mehreren Leuten gesprochen, die so gearbeitet haben. Gescheitert ist es bei ihnen am Pflegeaufwand. Die Spezifikationen konsistent weiterzuführen, während sich die Software ändert, hat mehr Probleme gemacht, als das Verfahren gelöst hat.

Zwei Beschreibungen, nur eine wird ausgeführt

Das Problem ist alt. Ich kenne es von jeder Dokumentation, die neben dem Code gepflegt werden sollte, und von den UML-Modellen, aus denen einmal der Code generiert werden sollte. Zwei Artefakte beschreiben dasselbe, und nur eines davon wird ausgeführt.

Der Code bekommt Rückmeldung vom Compiler, von den Tests und aus der Produktion. Die Spezifikation bekommt keine, und deshalb merkt niemand, wenn sie nicht mehr stimmt. Der Bugfix am späten Nachmittag landet im Code. Ob er auch in der Spezifikation landet, hängt an der Disziplin einer einzelnen Person, und ein Verfahren, das nur an Disziplin hängt, hält nach meiner Erfahrung nicht lange.

Mit einem Sprachmodell kommt ein zweiter Grund dazu. Dieselbe Spezifikation ergibt zweimal unterschiedlichen Code, und alles, was die Spezifikation offen lässt, wird erst im Code entschieden. Im Code steht also mehr als in der Spezifikation. Deshalb glaube ich nicht, dass die Spezifikation die Quelle der Wahrheit sein kann.

Ich spezifiziere trotzdem

Das klingt, als hielte ich nichts von Spezifikationen. Das Gegenteil stimmt. Ich schreibe Fachpläne, und ich bin dabei sehr penibel. In einem Fachplan steht, wie es ist und wie es werden soll, und dieser Plan treibt bei mir die Entwicklung.

Der Unterschied liegt in der Lebensdauer. Mein Fachplan beschreibt eine Änderung. Wenn sie umgesetzt ist, hat der Plan seinen Zweck erfüllt und muss ab da nicht mehr stimmen. Ich muss ihn nicht mit dem Code synchron halten, und deshalb habe ich keinen Pflegeaufwand.

Wenn ich wissen will, wie der Ist-Zustand aussieht, verlasse ich mich auf den Code und nicht auf ein Dokument. Das war früher mühsam, weil das Einlesen in fremden Code Tage gekostet hat, und daher kam auch der Wunsch nach einer gepflegten Beschreibung. Heute lasse ich mir vom Modell in Minuten aus dem Code herauslesen, wie ein Ablauf tatsächlich gebaut ist. Die Beschreibung des Ist-Zustands entsteht jedes Mal frisch und ist damit immer aktuell.

Was der Code nicht weiß

Eine Lücke bleibt. Der Code sagt mir, was das System tut. Er sagt mir nicht, warum es so gebaut wurde und welche Alternative verworfen wurde. Das Warum steht im Fachplan. Als Beschreibung des heutigen Stands taugt ein alter Fachplan nichts, aber in ihm kann ich nachlesen, warum etwas geändert worden ist.

Wenn ich eine Absicht dauerhaft festhalten will, schreibe ich sie als Test. Ein Test ist die einzige Spezifikation, die sich meldet, wenn sie nicht mehr stimmt.

Spec-Driven Development hat recht damit, dass vor dem Bauen sauber spezifiziert werden muss. Den Anspruch, die Spezifikation danach als Wahrheit fortzuschreiben, halte ich für den Teil, der in der Praxis nicht trägt. Die Wahrheit liegt immer noch im Code.

Wegen dieser Lücke ändere ich gerade mein claude-workflow-kit. Bisher kennt ein neuer Fachplan nur das, was gerade im Gespräch oder im Bestand steht. Frühere Fachpläne zum selben Thema sind unsichtbar, sobald sie archiviert sind, und mit ihnen die Gründe für frühere Entscheidungen. Künftig werden sie vor dem Schreiben gelesen, und was davon einschlägig ist, steht knapp im neuen Fachplan.

Fortgeschrieben wird dabei nichts. Ein alter Fachplan bleibt, wie er war, und er sperrt auch nichts. Widerspricht eine neue Anforderung einer früheren Entscheidung, landet das als Frage beim Product Owner, statt still überschrieben zu werden.