Spec Driven Development in einem regulierten Fachverfahren
Wie aus 89 Prozent fertig eine Sanierung in vier Wochen wurde
Bei der Übergabe fiel die Zahl mündlich: Die Software sei zu 89 Prozent fertig.
Nicht 85, nicht 90. Neunundachtzig. Eine Zahl, die Genauigkeit behauptet.
Auf dieser Grundlage wurde gerechnet. Noch rund zwei Monate bis zur Fertigstellung der Kernfunktion, dann Pilotbetrieb. Der Plan stand, der Termin stand, und es gab keinen Anlass, daran zu zweifeln.
Dann kamen neue Entwickler ins Projekt und sahen sich den Code an. Sie glaubten die 89 Prozent beim ersten Blick nicht.
Ende Mai lag ihr Urteil vor: bis Jahresende, und alles muss neu.
Gefragt hatte bis dahin niemand: 89 Prozent von was?
Eine Prozentzahl ohne Nenner
Ein Fertigstellungsgrad ist ein Bruch. Oben steht, was fertig ist, unten, was insgesamt zu bauen wäre. Die 89 hatte einen Zähler und keinen Nenner.
Es gab mehrere hundert Dokumente: Schnittstellenbeschreibungen, Fachhandbücher, technische Spezifikationen. Sie waren nicht wertlos, im Gegenteil, sie wurden später zum wichtigsten Material. Aber keines davon beschrieb, was das System tatsächlich tun muss. Sie waren technisch geschnitten, über Jahre gewachsen, in Teilen widersprüchlich, und sie beschrieben Zustände, die es so nicht mehr gab.
Ohne eine vollständige, aktuelle Beschreibung des Soll-Verhaltens lässt sich kein Fertigstellungsgrad berechnen. Man kann ihn schätzen. Dann ist er eine Meinung mit Nachkommastelle.
McMenamin und Palmer haben in den Achtzigern den Unterschied zwischen dem Wesen eines Systems und seiner technischen Umsetzung beschrieben. Was ein System fachlich leisten muss, ist etwas anderes als die Technik, in der es zufällig steckt. Die beiden Dinge wachsen über Jahre zusammen, bis niemand sie mehr trennen kann.
Genau diese Trennung war die Aufgabe. Der Gedanke ist über vierzig Jahre alt. Neu ist allein das Werkzeug, mit dem er sich bei dieser Materialmenge in vertretbarer Zeit durchführen lässt.
Zwei Codebasen, zwei Fragen
In Gesprächen über das Projekt verrutscht regelmäßig eine Unterscheidung.
Es gab zwei Codebasen.
Der Altbestand, rund 770.000 Zeilen in siebzig Dateien, die größte davon mit etwa 524.000 Zeilen. Ein Monolith, über viele Jahre gewachsen, im Betrieb und fachlich korrekt. Er beantwortet die Frage: Was muss gebaut werden? Er ist die Quelle der Spezifikation.
Die übernommene Produktbasis, der neue Stand, auf den sich die 89 Prozent bezogen. Sie beantwortet eine andere Frage: Was von dem bereits Gebauten ist zu retten?
Der Altbestand wurde gelesen und nicht angefasst. Die Produktbasis wurde gelesen und saniert.
Beide wurden rückwärts erschlossen, mit demselben Verfahren und zu verschiedenen Zwecken. Dass dasselbe Vorgehen zweimal funktioniert hat, ist der eigentliche Beleg dafür, dass es sich um eine Methode handelt und nicht um einen glücklichen Einzelfall.
Was Spec Driven Development hier bedeutet
Drei Schritte, auf beide Codebasen angewendet.
Erschließen. Der Code wird indexiert und durchsuchbar gemacht. Bei einer halben Million Zeilen in einer Datei ist das keine Lesearbeit, die ein Mensch in Wochen leistet.
Rekonstruieren. Aus dem Code wird die fachliche Logik zurückgewonnen und als strukturierte Beschreibung festgehalten. Am Ende standen 181 Ablauffunktionen mit insgesamt 28 Unterschritten, verifiziert gegen den Altbestand, und 188 modellierte Verfahrensschritte.
Verifizieren. Das ist der Schritt, der über die Qualität entscheidet. Jede rekonstruierte Annahme wird gegen die Menschen geprüft, die das Verfahren kennen. Eine Maschine, die 770.000 Zeilen liest, produziert plausible Ergebnisse. Plausibel ist nicht richtig.
Aus der Rekonstruktion entstand ein konsolidiertes Pflichtenheft mit 13 EPICs und rund 72 Funktionsanforderungen. Erst damit gab es einen Nenner. Und erst mit einem Nenner plus gemessenem Durchsatz lässt sich ein Fertigstellungsgrad rechnen, statt ihn zu behaupten.
Reuse statt Neubau
Die naheliegende Reaktion auf „alles muss neu" ist ein Neubau. Sie war falsch, und zwar aus einem Grund, der mit Budget nichts zu tun hat.
Ein Neubau kostet nicht in erster Linie Geld. Er kostet die Spezifikation. Jede Entscheidung, die über Jahre in das Altsystem eingeflossen ist, müsste neu getroffen werden, und niemand weiß mehr, warum sie damals so fiel. Ein Fachverfahren mit Rechtsfolge verzeiht das nicht.
Die Reihenfolge, die das Projekt tatsächlich durchlaufen hat, entspricht dem, was Rumelt den Kern einer Strategie nennt. Zuerst die Diagnose: Das Problem war nicht fehlende Entwicklungskapazität, sondern eine fehlende Bezugsgröße. Daraus die Leitlinie: Die Spezifikation wird rekonstruiert, nicht neu erfunden, und der Bestand wird wiederverwendet, wo er trägt. Und daraus die zusammenhängenden Handlungen: Erschließen, Rekonstruieren, Verifizieren, dann bauen.
Drei Komponenten aus dem Bestand wurden übernommen. Sie funktionierten, sie waren im Betrieb bewährt, und sie neu zu bauen hätte Wochen gekostet, ohne irgendetwas besser zu machen.
Was danach passierte: rund zwei Wochen Einrichtung, rund zwei Wochen Umsetzung. Zusammen vier Wochen, gegenüber einer Schätzung, die Ende Mai „bis Jahresende" lautete.
Drei Dinge gehören zu dieser Zahl, sonst ist sie geschönt. Die zwei Wochen Einrichtung sind eingerechnet und werden nicht herausgerechnet. „Bis Jahresende" war eine Einschätzung erfahrener Entwickler, kein gemessener Vergleichswert. Und der Umfang am Ende war größer als ursprünglich geplant: Es kamen die Trennung von Logik und Oberfläche sowie die Mandantenfähigkeit dazu, beides stand vorher nicht im Plan.
Drei Prüfschichten
Wer Code maschinell erzeugen lässt, verschiebt die Arbeit. Es entsteht nicht weniger Arbeit, sondern mehr ungeprüfte.
Maschinell erzeugter Code ist dabei selten offensichtlich falsch. Er ist plausibel. Variablen heißen richtig, die Struktur passt zum übrigen Repository, die Tests sind grün. Ein Mensch, der sein eigenes Missverständnis in Code schreibt, hinterlässt meistens Spuren davon. Eine Maschine, die eine Vorgabe falsch interpretiert, hinterlässt sauberen Code mit einer falschen Annahme darin.
Deshalb drei Schichten, die verschiedene Fragen stellen.
Technisch. Stimmt der Code? Das ist das klassische Code-Review und die günstigste der drei Schichten.
Fachlich. Verhält sich das Verfahren richtig? Dafür gab es über rund drei Wochen hinweg fünfzehn fachliche Test-Sessions, über den kompletten Lebenszyklus eines Vorgangs, auf zwei Ebenen: automatisiert gegen die Schnittstellen und manuell gegen das Verhalten. Das Ergebnis wurde zusätzlich auf Quellcode-Ebene gegen den Altbestand abgeglichen.
Diese Schicht fand elf Fehler, die als Ticket erfasst wurden, plus sechs weitere dokumentierte Befunde. Bei einem davon war der Code technisch einwandfrei und das Verfahren wäre trotzdem falsch gelaufen: Ein Schritt wäre ausgelöst worden, der zugehörige zweite nie. Aufgefallen wäre das erst Wochen später bei einem Abgleich.
Bedienseitig. Kann ein Anwender damit arbeiten? Diese Schicht fand drei Stellen, an denen das neue System gegen Vorgaben verstieß, die das Projekt sich selbst gegeben hatte.
Das ist der unangenehme Teil, und er gehört in diesen Text. Ein Prüfregime, das nichts findet, hat nicht geprüft.
Was die Spezifikation nicht enthält
Eine rekonstruierte Spezifikation beschreibt, wie sich ein System verhalten muss. Über die Bedienung sagt sie nichts.
Mit der fachlichen Logik übernimmt man deshalb auch die Bedienlogik des Altsystems. Samt der Umwege, die vor fünfzehn Jahren aus technischen Gründen entstanden sind und seitdem als normal gelten.
Sichtbar wurde das über das Supportaufkommen des Altsystems. Anwender riefen an, um zu erfahren, welchen Knopf sie drücken müssen. Nicht, weil sie das Verfahren nicht kannten, sondern weil die Software es nicht zeigte.
Die Frage ist in diesen Fällen nicht, was das System können muss. Sie lautet, was jemand eigentlich erledigen will, wenn er sich an diesen Bildschirm setzt. Diese Frage beantwortet keine Spezifikation, egal wie vollständig sie ist.
Was ich nicht behaupte
Das Projekt läuft. Es gibt keinen Go-Live und keine Erfolgsmeldung. Was hier steht, ist ein Zwischenstand.
Der Zeitvergleich stützt sich auf eine Entwicklerschätzung, nicht auf einen gemessenen Vergleichswert. Die Einrichtungszeit ist eingerechnet.
Die Testabdeckung ist nicht vollständig. Die Lücken sind bekannt und werden mitgeführt.
Es gibt keine Zahlen zu eingesparten Kosten, weil keine belastbaren vorliegen. Alles, was ich dazu sagen könnte, wäre geschätzt.
Der Befund zur Bedienung ist eine Einschätzung aus Supportdaten und Gesprächen, kein gemessener Wert.
Was übertragbar ist
Das Werkzeug ist austauschbar und in zwei Jahren ein anderes. Übertragbar ist die Reihenfolge.
Vor dem Weiterbauen wurde nachgesehen. Das ist der Hebel, nicht die Technik. Ohne das Review Ende Mai wäre monatelang auf einer Basis weitergebaut worden, deren Zustand niemand kannte.
Und eine Prozentzahl ist nur so viel wert wie ihr Nenner. Wenn niemand sagen kann, wogegen gemessen wird, ist jeder Fortschrittsbericht eine Meinung.
Transparenz: Dieser Text ist mit KI-Unterstützung auf Grammatik und Dramaturgie überarbeitet. Inhalt, Zahlen und Entscheidungen sind meine.