Software wird nie fertig

Es gibt Lektionen, die man nur über Jahre lernt, weil sie sich nur über Jahre zeigen. Diese ist eine davon. Sie ist bewusst allgemein gehalten — ohne Kunden, ohne Projekt, ohne Zeitpunkt.

Situation

In dem am längsten laufenden Kundenprojekt begleitete ein System seine Aufgabe über einen langen Zeitraum. Nichts an dieser Geschichte ist dramatisch: Das System lief, wurde gebraucht, wurde weiterentwickelt. Genau in dieser Unspektakularität liegt die Lektion — nicht in einem Ereignis, sondern in dem, was die Dauer sichtbar machte.

Ausgangsannahmen

Am Anfang steht, ausgesprochen oder nicht, die Vorstellung eines Endzustands: Irgendwann ist das System fertig, die Anforderungen erfüllt, die Arbeit getan. Diese Vorstellung prägt, wie man baut — man richtet das System auf den bekannten Bedarf aus, so genau wie möglich. Fertig zu werden erscheint als Ziel.

Problem

Über die Jahre erwies sich der Endzustand als Fiktion. Die Anforderungen hörten nicht auf, sich zu ändern — nicht, weil etwas falsch geplant war, sondern weil sich die Welt ändert, in der das System steht: neue Bedürfnisse, neue Gegebenheiten, neue Fragen, die beim Bau niemand kannte. Ein System, das für einen festen Endzustand gebaut ist, wird gegen diese fortlaufende Veränderung mit jedem Jahr spröder. Was einmal genau passte, sitzt später zu eng.

Ursache

Die Ursache war die Annahme des Endzustands selbst. Wer glaubt, ein System werde fertig, optimiert es auf den heute bekannten Bedarf und macht es damit gegen den unbekannten von morgen unbeweglich. Der Fehler liegt nicht im Ändern der Anforderungen — das ist der Normalfall —, sondern in einer Architektur, die so tut, als käme dieser Normalfall nicht. Je genauer man auf das Heute baut, desto teurer wird das Morgen.

Entscheidung

Die Lehre war, den Endzustand als Ziel aufzugeben und ein anderes an seine Stelle zu setzen: nicht ein fertiges System, sondern ein änderbares. Die entscheidende Frage ist nicht mehr „ist es fertig?", sondern „wie teuer ist die nächste Änderung?" — und die Architektur wird daran gemessen, nicht an der Passgenauigkeit auf den heutigen Stand.

Umsetzung

Praktisch heißt das, das System so zu bauen, dass Veränderung billig bleibt: klare Grenzen, damit eine Änderung lokal bleibt; wenig Kopplung, damit ein Eingriff nicht überallhin ausstrahlt; die Fachlichkeit so ausgedrückt, dass sie sich anpassen lässt, ohne alles zu berühren. Nicht die perfekte Passung auf heute, sondern die günstige Anpassbarkeit auf morgen ist das Maß. Über die lange Laufzeit hat sich das immer wieder bezahlt gemacht — jede Anforderung, die kam, kostete weniger, als sie in einem starr optimierten System gekostet hätte.

Trade-offs

Für Änderbarkeit zu bauen bedeutet, auf einen Teil der maximalen Passung auf den heutigen Bedarf zu verzichten. Ein System, das jede künftige Änderung günstig hält, ist im Moment selten das eleganteste für den einen aktuellen Fall. Das ist der bewusste Preis. Anders würden wir nur bei einem absehbar kurzlebigen System entscheiden — dort ist die Investition in Änderbarkeit verschwendet, weil das Morgen, für das man vorsorgt, nicht kommt.

Was wir gelernt haben

Software wird nie fertig, weil die Welt nicht fertig wird. Anforderungen ändern sich fortlaufend, und das ist kein Mangel, sondern die Bedingung, unter der Software lebt. Die einzige belastbare Antwort darauf ist eine Architektur, die Veränderung billig macht — nicht eine, die auf einen Endzustand hin optimiert, den es nie gibt. Der Wert eines langlebigen Systems bemisst sich nicht daran, wie gut es heute passt, sondern daran, wie wenig die nächste Änderung kostet.

Wie das Batunet verändert hat

Seither versprechen wir kein fertiges System, sondern ein änderbares — und messen unsere Arbeit daran, wie günstig die nächste Anforderung zu erfüllen ist. Wir behandeln fortlaufende Veränderung als den Normalfall, für den man baut, nicht als Störung eines Plans. Das nimmt dem „nie fertig" das Bedrohliche: Es ist keine Schwäche des Projekts, sondern die Natur der Sache — und man kann für sie entwerfen.

Weiterführend

• Guide: Software, die in zehn Jahren noch läuft — warum Änderbarkeit das eigentliche Maß über die Lebensdauer ist.
• Guide: Warum Softwareprojekte wirklich scheitern — warum frühe, starre Festlegung teuer wird, wenn das Verständnis wächst.
• Guide: Legacy-Modernisierung ohne Big Bang — wie man ein langlebiges System über Jahre weiterentwickelt.
• Decision: Modularer Monolith als Ausgangspunkt — Grenzen, die Änderungen lokal halten.

Grundlage ist die Batunet Engineering Method: für Veränderung bauen, nicht für einen Endzustand — und Änderbarkeit zum Maßstab machen.

„Fertig" ist kein Zustand, den Software erreicht, sondern eine Vorstellung, die man loslassen muss. Was bleibt, ist die Frage, wie viel die nächste Änderung kostet.