TheWhiteCode

Vierzehn Monate. In dieser Zeit habe ich ein Semester beendet, zwei Prüfungen geschrieben und einen Bot fast in den Ruin getrieben. Und in dieser Zeit ist in dem Projekt, in dem ich als Hilfskraft saß, keine einzige Zeile produktiver Code entstanden. Was entstanden ist: ein Lastenheft mit 180 Seiten und drei Terminverschiebungen.

Ich habe das lange für Bürokratie gehalten. Das war die Meinung, die ich mir am dritten Abend gebildet hatte, an dem wir über die Formulierung „bedarfsgerecht" diskutiert haben. Inzwischen halte ich es für die ehrlichste Form von Softwareentwicklung, die ich gesehen habe, und gleichzeitig für eine, die ich nicht ertragen würde.

Wo die vierzehn Monate hingehen

Ich habe die Etappen mitgeschrieben, weil ich am Anfang dachte, es sei ein Projekt ohne Plan. Es war ein Projekt mit einem Plan, dessen Etappen alle denselben Zweck hatten: sicherstellen, dass später niemand sagen kann, er habe es nicht gewusst.

Die Markterkundung war die Phase, die mich am meisten überrascht hat. Zwei Monate Gespräche, in denen Anbieter erklärten, was sie schon haben, und wir erklärten, was wir brauchen. Danach wurde das Lastenheft geschrieben, als hätte es diese Gespräche nie gegeben. Auf meine Frage, warum, hat jemand gesagt: „Weil wir sonst den Anbieter beschreiben und nicht den Bedarf."

Ein Lastenheft ist ein Wunschzettel mit Fristen

Ein Lastenheft darf nicht beschreiben, wie etwas gebaut wird. Es beschreibt, was passieren muss, wenn jemand eine Bestellung storniert, und überlässt die Frage, ob das ein Event, ein Cronjob oder ein Trigger ist, dem Anbieter. Das klingt selbstverständlich und ist in der Praxis wahnsinnig schwer, weil jeder Satz, der mit „über eine Schnittstelle" anfängt, schon eine Lösung ist.

Der Satz, an dem wir drei Wochen gesessen haben, war: „Die Verarbeitung erfolgt zeitnah." Drei Wochen für zwei Wörter. Am Ende stand dort eine Frist von 15 Minuten für 95 Prozent der Fälle und ein Messverfahren. Das ist keine Pedanterie, das ist der Unterschied zwischen einem Vertrag und einem Wunsch.

Warum ich trotzdem nicht spotte

Die Versuchung ist groß, das Ganze als Beweis für Verschwendung zu lesen. Vierzehn Monate für ein Lastenheft, während ein Startup in derselben Zeit ein Produkt baut. Aber die Ausschreibung ist nicht für das Produkt da, sie ist für die Rechtfertigung da. Wenn hinterher jemand fragt, warum dieser Anbieter und nicht der billigere, muss es eine Antwort geben, die nicht „weil wir ihn kennen" lautet.

Für mich persönlich ist das trotzdem nichts. Ich habe in diesen vierzehn Monaten gelernt, wie man Anforderungen schreibt, und ich habe gemerkt, dass ich nach drei Wochen ohne Rückmeldung aus dem Code unruhig werde. Das ist keine Kritik an der Ausschreibung. Es ist eine Erkenntnis über mich.

Was ich dabei gelernt habe und vorher nicht wusste: Der Aufwand für eine schlechte Ausschreibung ist nicht null, er verschiebt sich nur. Ein unklares Lastenheft führt nicht zu einem günstigeren Angebot, sondern zu Nachträgen. In dem Projekt, das ich begleitet habe, gab es am Ende drei Nachträge mit einem Volumen von 18 Prozent der Auftragssumme, alle wegen Formulierungen, über die wir sechs Monate vorher diskutiert hatten. Die Diskussion war billiger als der Nachtrag, und trotzdem hat sie sich wie Stillstand angefühlt. Das ist die eigentliche Lektion: Bürokratie ist manchmal nur die Rechnung, die man später bezahlt, wenn man sie vorher nicht bezahlen will.

Was ich daraus für mein Projekt mitnehme

Mein Bot hat jetzt eine Datei namens anforderungen.md, sieben Zeilen lang. Sie beschreibt nicht, wie ich etwas baue, sondern was passieren muss: Bei einem Verbindungsfehler darf keine Order doppelt gesendet werden. Ein Trade über 50 Euro braucht eine Bestätigung. Wenn die Datenbank länger als zehn Sekunden nicht antwortet, wird der Bot gestoppt, nicht neu gestartet.

Drei dieser Sätze habe ich erst geschrieben, nachdem ich gegen sie verstoßen habe. Das ist der Teil, den mir das Lastenheft beigebracht hat: Der Wert liegt nicht darin, alles vorher zu wissen, sondern darin, die Sätze aufzuschreiben, bevor sie teuer werden.

Fazit

Vierzehn Monate ohne Code sind kein Beweis für Langsamkeit. Sie sind der Preis dafür, dass eine Entscheidung später überprüfbar ist. Ich würde in diesem Tempo nicht arbeiten wollen, und ich bin froh, dass ich es einmal von innen gesehen habe: Es hat meine Meinung über Bürokratie weniger freundlich und meine Meinung über meine eigenen Abkürzungen deutlich strenger gemacht.

Wenn du dein letztes Projekt in sieben Sätzen beschreiben müsstest, bevor du es baust: Welcher dieser Sätze hätte dir die meiste Arbeit erspart?