Software, die in zehn Jahren noch läuft

Die meiste Software wird für die Demo gebaut, nicht für das Jahrzehnt. Sie funktioniert am Tag der Abnahme und wird danach jedes Jahr teurer zu ändern, bis niemand mehr weiß, warum sie so ist, wie sie ist. Dieser Text handelt von der anderen Art: Systemen, die auch in zehn Jahren noch laufen — und sich in zehn Jahren noch sicher ändern lassen.

„Zehn Jahre" heißt nicht „unverändert". Software, die zehn Jahre unangetastet überlebt, ist entweder trivial oder tot. Gemeint ist etwas anderes: Das System läuft noch, es lässt sich noch zu vertretbaren Kosten ändern, es ist noch verständlich, und es lässt sich noch betreiben. Langlebigkeit ist keine Eigenschaft des Codes am ersten Tag. Sie ist eine Eigenschaft der Kosten jeder Änderung über die Jahre.

Deshalb ist die Frage nicht technisch. Kein Framework und keine Sprache macht Software langlebig — die Entscheidungen davor tun es: wo die Grenzen liegen, was wovon abhängt, was umkehrbar bleibt und ob das Warum erhalten bleibt.

Warum die meiste Software teuer wird

Software wird einmal geschrieben und ein Jahrzehnt gelesen und geändert. Die Kosten stecken fast nie im Schreiben. Sie stecken im Ändern — und die teuerste Änderung ist die, die überall zugleich anfassen muss.

Systeme werden selten durch eine einzelne falsche Entscheidung teuer. Sie werden es durch Anhäufung: Geschäftslogik, die über Controller, Models und Views verstreut ist; Abhängigkeiten, die niemand mehr überblickt; Entscheidungen, deren Begründung verloren ging; Fehlerfälle, die niemand kennt, bis die Produktion sie zeigt. Jede dieser Kleinigkeiten ist für sich harmlos. Zusammen führen sie zu dem Punkt, an dem eine kleine fachliche Änderung eine große technische wird — und an dem niemand mehr mit Sicherheit sagen kann, was sie noch kaputt macht.

Die gemeinsame Wurzel ist fast immer dieselbe: Das System wurde für den Launch optimiert, nicht für das Jahrzehnt. Die Rechnung kommt später — als Änderungskosten, die mit jedem Jahr steigen.

Die Empfehlung ist deshalb unbequem: Optimieren Sie auf die Kosten der Änderung, nicht auf die Geschwindigkeit der ersten Auslieferung. Der Preis dafür ist real. Es ist am Anfang langsamer und teurer; ein auf den Launch optimiertes System ist früher fertig und zunächst billiger. Anders entscheiden wir bei echten Wegwerf-Prototypen, bei einem Markttest, der verworfen werden soll, und bei einer harten externen Frist, deren Verstreichen das Produkt sinnlos macht. Dort optimiert man auf die Demo — und plant den Neubau von vornherein ein, statt den Prototyp aus Versehen in Produktion altern zu lassen.

Schema: Kopplung bestimmt die Reichweite einer Änderung.

Was Software gut altern lässt

Software altert gut, wenn sie verständlich und änderbar bleibt. Alles andere folgt daraus. Zwei Kräfte bestimmen, ob das gelingt: Kopplung und verlorener Kontext. Steigt die Kopplung, wird jede Änderung großflächig. Geht der Kontext verloren, wird jede Änderung zum Rätsel. Codestil, Formatierung und die Wahl der Sprache sind demgegenüber nachrangig.

Konkret altern die Systeme gut, in denen eine typische Änderung lokal bleibt, die tragenden Entscheidungen wenige und begründete sind, Grenzen halten, Fehlerfälle bekannt sind und ein neuer Mensch das Warum noch nachlesen kann. Das sind keine Stilfragen, sondern Eigenschaften der Struktur.

Dazu gehört die Wahl der Technik. Wir bevorzugen ausgereifte Technik vor Neuheit — nicht aus Vorsicht, sondern weil ihre Grenzen bekannt sind und in fünf Jahren noch jemand sie versteht. Der Preis: Man verzichtet auf die Vorteile neuerer Werkzeuge und schreibt gelegentlich mehr selbst, wo ein neueres Werkzeug Bequemlichkeit geboten hätte. Anders entscheiden wir, wenn eine ausgereifte Option eine harte Anforderung nachweislich nicht erfüllt — oder wenn das Neue für dieses konkrete Problem längst die ausgereifte, verstandene Wahl ist. „Ausgereift" meint verstanden und gepflegt, nicht alt und verwaist; diese Unterscheidung ist der ganze Punkt.

Beobachtungen aus langlebigen Systemen

Wer Systeme über Jahre begleitet, sieht dieselben Muster wiederkehren — unabhängig von Sprache, Branche und Team. Keine Geschichten, sondern Beobachtungen:

• Die Teile, die sich am häufigsten ändern, sind selten die, für die man Flexibilität eingebaut hat. Beweglichkeit entsteht dort, wo sie nie gebraucht wird, und Starrheit dort, wo geändert werden muss.
• Die echten Grenzen eines Systems zeigen sich in seinen Incidents, nicht in seinem Architekturdiagramm.
• Was zuerst verloren geht, ist das Warum; was als Zweites verloren geht, ist, wen man dazu fragen könnte.
• Die Datenbank überlebt jede Anwendungsschicht über ihr. Schema-Entscheidungen sind die am schwersten umkehrbaren des ganzen Systems.

Architekturentscheidungen, die überleben

Nicht alle Entscheidungen sind gleich. Einige sind tragend — sie bestimmen, wo die Grenzen des Systems verlaufen, was die Domäne ist, was wovon abhängt und was sich später ersetzen lässt. Diese Entscheidungen überleben, wenn sie wenige sind, bewusst getroffen, aufgeschrieben und unabhängig von Mode. Der Rest sind Details, die man günstig ändern kann.

Die erste tragende Entscheidung betrifft die Geschäftslogik. Sie gehört in die Domäne, unabhängig vom Framework. Das Framework ist Infrastruktur — der Ort, an dem HTTP, Persistenz und Auslieferung passieren — nicht der Ort der fachlichen Regeln. Der Preis dieser Trennung ist Indirektion: mehr Code, eine Abstraktion, die gepflegt werden muss, und anfangs weniger Feature-Geschwindigkeit, weil man nicht direkt im Framework arbeitet. Anders entscheiden wir bei kleinen, kurzlebigen Werkzeugen und bei Anwendungen, die im Kern nichts als das Framework sind — eine reine CRUD-Oberfläche etwa. Dort ist die Kopplung an das Framework kein Fehler, sondern die angemessene Einfachheit.

Schema: Abhängigkeiten zeigen nach innen; die Domäne hängt von nichts ab.

Die zweite betrifft den Zuschnitt. Unsere Voreinstellung ist der modulare Monolith: ein Deployable, klare Modulgrenzen im Inneren. Der Preis gegenüber verteilten Diensten: Man skaliert Teams und Teile nicht unabhängig, und ein schlecht abgegrenztes Modul kann andere beeinträchtigen; die Modulgrenzen halten nur mit Disziplin, weil nichts sie technisch erzwingt. Anders entscheiden wir, wenn es echte, dauerhafte Gründe für die Teilung gibt — unabhängige Skalierung einzelner Teile, organisatorische Grenzen zwischen Teams, regulatorische Isolation. Dann schneiden wir, aber entlang dieser realen Grenzen, nicht aus Prinzip.

Was diese Entscheidungen überleben lässt, ist weniger ihre Richtigkeit als ihre Sichtbarkeit: Sie sind explizit getroffen und begründet, nicht nebenbei entstanden. Eine tragende Entscheidung, die niemand als solche erkannt hat, ist die gefährlichste — weil niemand sie bewacht.

Warum Umkehrbarkeit zählt

Wir sagen die Zukunft nicht voraus; wir halten Änderung günstig. Das ist keine Bescheidenheit, sondern die einzige Haltung, die über zehn Jahre trägt, denn die Anforderungen von morgen kennt heute niemand. Statt auf die richtige Vorhersage zu wetten, entwerfen wir so, dass eine falsche Annahme billig zu korrigieren ist.

Der Schlüssel ist die Unterscheidung zwischen Entscheidungen, die sich leicht zurücknehmen lassen, und solchen, die es nicht tun. Eine leicht umkehrbare Entscheidung trifft man schnell und korrigiert sie bei Bedarf. Eine teuer umkehrbare — ein öffentliches Datenformat, ein Vertrag nach außen, die Wahl des Persistenzmodells — trifft man langsam und schreibt das Warum auf.

Die Empfehlung: Wählen Sie im Zweifel die umkehrbare Option und kapseln Sie die unumkehrbaren hinter Grenzen, damit ihre Reichweite begrenzt bleibt. Der Preis ist, dass ein umkehrbarer Entwurf für den heutigen Fall selten der optimale ist — eine Schnittstelle, die man vielleicht nie braucht, oder eine Grenze, die einen zusätzlichen Aufruf kostet. Anders entscheiden wir bei einer erprobten, stabilen Anforderung, die sich nicht ändern wird — ein vorgeschriebenes Format, eine feste gesetzliche Regel. Dort ist die Abstraktion Verschwendung; man legt sich direkt fest.

Schema: Umkehrbares schnell; Unumkehrbares gekapselt und begründet.

Umkehrbarkeit hat eine zweite Hälfte, die oft vergessen wird: das festgehaltene Warum. Eine Entscheidung, deren Begründung verloren ist, lässt sich nicht sicher zurücknehmen, weil niemand mehr weiß, was sie ursprünglich abwog. Deshalb ist das Aufschreiben des Warum kein Papierkram, sondern Teil der Umkehrbarkeit selbst.

Die Rolle des Testens

Tests haben nicht den Zweck, eine Abdeckungszahl zu erreichen. Ihr Zweck ist, Änderung sicher zu machen. Der Wert eines Tests bemisst sich an der Änderung, die er erlaubt — nicht daran, dass er existiert. Eine hohe Abdeckung über belanglosem Code kauft nichts; ein einziger Test über der teuersten Regel kauft Ruhe bei jeder späteren Änderung.

Deshalb testen wir dort, wo Fehler teuer sind: im fachlichen Kern und auf den Pfaden, deren Bruch echten Schaden anrichtet. Den schwierigsten Pfad beweisen wir früh und End-to-End, bevor die Breite entsteht — Risiko wird am Anfang ausgeräumt, nicht am Ende entdeckt.

Der Preis ist, dass jeder Test selbst Code ist, den man pflegt. Zu viel davon verlangsamt Änderung und zementiert einen Entwurf, den man vielleicht noch verwerfen will; zu wenig macht jede Änderung zur Mutprobe. Anders entscheiden wir bei Wegwerf-Code und bei explorativen Spikes, deren Ergebnis noch offen ist — dort wird noch nicht getestet, weil noch nicht feststeht, was bleiben soll. Sobald etwas bleibt und teuer zu brechen ist, kommt der Test.

Die Rolle der Dokumentation

Der Code sagt, was das System tut. Er sagt fast nie, warum es so und nicht anders gebaut ist. Genau dieses Warum ist das Erste, was verloren geht, und sein Verlust macht jede spätere Änderung zum Rätselraten. Die haltbare Dokumentation ist deshalb nicht die vollständige, sondern die, die Entscheidungen und ihre Abwägungen festhält.

Die Empfehlung: Dokumentieren Sie Entscheidungen und ihre Trade-offs — kurze Decision Records — nicht jede Funktion. Der Preis ist Zeit, und Dokumentation kann veralten; eine falsche Doku ist schlechter als keine, weil sie in die Irre führt. Anders entscheiden wir bei trivial umkehrbaren Entscheidungen: Was nichts kostet zu ändern, ist keinen Eintrag wert.

Die Konsequenz ist kein Verzicht, sondern Zuschnitt: Wir dokumentieren das Langsame — Entscheidungen, Grenzen, Betrieb — nicht die Implementierungsdetails, die sich ohnehin ständig ändern. Dokumentation über dem Schnellen ist am Tag nach dem Schreiben falsch; über dem Langsamen hält sie Jahre.

Die Rolle des Betriebs

Software endet nicht beim Launch. Ein System, das zehn Jahre laufen soll, wird zehn Jahre betrieben — und der Betrieb entscheidet mit darüber, ob es sie erreicht. Ein System, dessen Fehlerfälle unbekannt sind, ist nicht fertig, sondern nur noch nicht aufgefallen.

Zwei Dinge gehören deshalb an den Anfang, nicht in den ersten Incident. Erstens Beobachtbarkeit: Man muss von außen sehen, was innen passiert, bevor etwas schiefgeht. Zweitens der Entwurf für den Fehlerfall: Man probt, wie das System sich verhält, wenn eine Abhängigkeit ausfällt, bevor die Produktion die Antwort erzwingt.

Schema: Beobachtbarkeit zeigt das Signal, bevor die Schwelle zum Ausfall wird.

Der eigentliche Prüfstein ist nicht der ruhige Tag, sondern der Incident um drei Uhr nachts, behandelt von jemandem, der das System nicht gebaut hat. Unter Druck steigt niemand auf das Niveau seines Entwurfs; man fällt auf das Niveau dessen, was vorbereitet ist. Vier Dinge entscheiden dann: ob man sieht, was passiert (Beobachtbarkeit); ob der Schaden begrenzt bleibt, statt sich auszubreiten (Isolation, kleiner Wirkungsradius); ob sich die letzte Änderung schnell zurücknehmen lässt (umkehrbare Auslieferung); und ob es einen geprobten Weg gibt statt Improvisation. Weil die meisten Ausfälle einer Änderung folgen und nicht der Last, ist die schnellste Erholung fast immer, die Änderung rückgängig zu machen — was voraussetzt, dass Änderungen klein und umkehrbar sind.

Die Empfehlung: Bauen Sie Beobachtbarkeit von Tag eins ein und entwerfen Sie für den Menschen, der das System unter Druck bedient — klare Signale, kleiner Wirkungsradius, schnelles Rollback, geprobter Fehlerfall. Der Preis ist Aufwand, der am guten Tag nichts produziert: Instrumentierung, Rollback-Maschinerie, geprobte Ausfälle, etwas Latenz. Anders entscheiden wir bei Systemen, die Ausfälle vertragen — ein internes Werkzeug etwa. Dort darf die Tiefe geringer sein, aber die Signale bleiben; auch das interne Werkzeug muss man verstehen, wenn es um drei Uhr klemmt.

Dazu gehört die Auslieferung selbst: kleine, umkehrbare Schritte, ohne Ausfallzeit, wo Verfügbarkeit zählt. Der Preis ist mehr Auslieferungsmaschinerie; anders entscheiden wir, wo ein kurzes Wartungsfenster akzeptiert ist und Einfachheit den Ausschlag gibt.

Die Rolle von Standards

Standards sind gemeinsame Konventionen — verbreitete Formate, bekannte Schnittstellen, Grenzen, die den einzelnen Menschen überdauern. Ihr Wert für die Langlebigkeit ist doppelt: Sie senken die Kosten, mit denen ein neuer Mensch das System versteht, und die Kosten, mit denen ein Teil ersetzt wird. Ein System aus bekannten Bausteinen kann man auch in fünf Jahren noch einstellen; ein System aus lauter Eigenbauten muss man erst wieder erlernen.

Die Empfehlung: Bevorzugen Sie langweilige, verbreitete Schnittstellen und Konventionen — HTTP, SQL, etablierte Formate — vor eigenen Lösungen. Der Preis ist, dass ein Standard selten perfekt passt und eine maßgeschneiderte Lösung für den exakten Fall effizienter sein kann; man nimmt etwas Ineffizienz und eine gewisse Einschränkung in Kauf. Anders entscheiden wir an einem nachgewiesenen Engpass, an dem der Standard messbar das Problem ist — dort optimiert man lokal und hinter einer Grenze, nicht im ganzen System.

Auch die Konsistenz innerhalb einer Codebasis ist ein Standard. Eine Regel, die überall gleich angewandt wird, ist mehr wert als die je Stelle beste Einzellösung, weil sie das System als Ganzes lesbar hält.

Menschen wechseln. Software bleibt.

In zehn Jahren wechselt ein Team vollständig durch. Die Menschen, die ein System gebaut haben, sind lange vor dem System wieder weg — und mit ihnen das Wissen, das nur in Köpfen stand. Verständlichkeit ist deshalb keine Höflichkeit gegenüber Nachfolgern, sondern die Bedingung dafür, dass die Software ihre Autoren überlebt.

Der Prüfstein ist hart: Kann ein kompetenter Fremder eine Änderung sicher vornehmen — allein aus Code, Entscheidungen, Grenzen und Betrieb, ohne einen der ursprünglichen Autoren? Lautet die Antwort „nur, wenn man X fragt", hängt das System an einer Person, nicht an sich selbst. Dann wird jeder Weggang zum Risiko und jede Einstellung zu Monaten Archäologie.

Die Empfehlung: Schreiben Sie für den Leser, der noch nicht da ist — Dinge benannt nach dem, was sie tun, das Warum festgehalten, Grenzen explizit, Cleverness nur dort, wo sie sich erklärt. Der Preis ist, dass das langsamer ist als für sich selbst zu schreiben und redundant wirkt, solange das ursprüngliche Team noch da ist. Anders entscheiden wir nur bei kurzlebigem Code, dessen Autor sein einziger Leser bleibt. Alles, was das Jahrzehnt erreichen soll, wird für Fremde geschrieben.

Häufige Fehler

Die immer gleichen Muster machen Software vorzeitig teuer:

Optimieren auf den Launch statt auf die Änderungskosten. Geschäftslogik in Controllern und Models statt in der Domäne — jede fachliche Änderung wird zur technischen. Vorzeitige Verteilung: Microservices und Abstraktionen als Ausgangspunkt statt als Antwort auf ein konkretes Problem. Kopplung an das Framework ohne Not. Technikwahl nach Mode statt nach Kontext und Lebensdauer. Verlorenes Warum, weil Entscheidungen nie festgehalten wurden. Und beides falsch beim Testen zugleich — alles zu testen und den Entwurf zu zementieren, oder nichts und jede Änderung zur Mutprobe zu machen.

Keiner dieser Fehler ist am ersten Tag sichtbar. Alle werden es später — als Änderungskosten, die niemand eingeplant hat.

Wann Komplexität gefährlich wird

Komplexität entsteht von allein. Einfachheit muss entworfen werden. Deshalb ist die Richtung der Vorsicht klar: Wir fügen keine Struktur hinzu, bevor sie gebraucht wird, und wir entfernen keine, die trägt.

Gefährlich wird Komplexität, wenn sie kein reales Problem bezahlt — wenn sie für eine Zukunft eingebaut wird, die vielleicht nie kommt: eine Abstraktion für den zweiten Anwendungsfall, den es noch nicht gibt, ein verteiltes System für eine ungemessene Last, eine Schnittstelle für einen Anbieterwechsel, den niemand plant. Jede dieser Vorwegnahmen kostet dauerhaft Verständlichkeit und zahlt sich nur aus, wenn die vermutete Zukunft eintritt.

Die Empfehlung: Fügen Sie Komplexität nur gegen ein gegenwärtiges, benanntes Problem hinzu. Der Preis dieser Zurückhaltung ist, dass man gelegentlich später unter Druck nachrüsten muss — eine Grenze nachträglich einzuziehen kostet mehr, als sie von Anfang an gehabt zu haben. Anders entscheiden wir, wenn der künftige Bedarf nahezu sicher und jetzt billig einzubauen ist: ein bekannter zweiter Markt, eine vertraglich zugesagte Integration. Dann legt man die Naht früh — aber gegen etwas Konkretes, nicht gegen ein Gefühl.

Checkliste

Fragen, die eine CTO an das eigene System stellen kann. Es sind Diagnosefragen, keine Urteile — die Antworten sagen, wo ein System steht, nicht ob es „bestanden" hat.

• Bleibt eine typische Änderung lokal, oder pflanzt sie sich fort? Fortpflanzung ist das erste Zeichen zu hoher Kopplung.
• Können wir noch benennen, warum die tragenden Entscheidungen so getroffen wurden? Ist das Warum weg, ist jede Änderung ein Rätsel.
• Ist die Geschäftslogik unabhängig vom Framework? Sonst wird jede fachliche Änderung zur Infrastrukturänderung.
• Welche Entscheidungen sind unumkehrbar — und sind sie gekapselt? Unumkehrbares ohne Grenze ist das größte Risiko.
• Sind die teuer zu brechenden Pfade getestet — und nur diese? Beides, zu viel und zu wenig, macht Änderung schwer.
• Sind die Fehlerfälle bekannt und geprobt? Ein unbekannter Fehlerfall ist ein noch nicht eingetretener Ausfall.
• Könnte ein neuer erfahrener Mensch das System aus dem Geschriebenen verstehen? Wenn nicht, hängt es an Köpfen.
• Gibt es Komplexität ohne gegenwärtiges Problem, das sie bezahlt? Solche Komplexität ist reiner Verlust.
• Betreiben wir, was wir gebaut haben — mit Beobachtbarkeit von Tag eins? Betrieb entscheidet über die zehn Jahre mit.
• Ließe sich ein Teil ersetzen, ohne das Ganze neu zu schreiben? Ersetzbarkeit ist die praktische Prüfung der Grenzen.

FAQ

Heißt langlebig, dass man nichts mehr ändert? Im Gegenteil. Langlebig heißt, dass Änderung günstig bleibt. Ein System, das man nicht mehr anfassen kann, ist nicht langlebig, sondern erstarrt — und erstarrte Systeme werden ersetzt, sobald die Welt sich weiterdreht.

Ist ausgereifte Technik nicht ein Risiko? Nur wenn man ausgereift mit alt und verwaist verwechselt. Ausgereift meint: verstanden, gepflegt, mit bekannten Grenzen. Das Risiko liegt eher umgekehrt — bei der neuen Technik, deren Grenzen noch niemand kennt und die in fünf Jahren vielleicht niemand mehr pflegt.

Kostet das nicht einfach mehr? Am Anfang ja. Über das Jahrzehnt nein, weil die Änderungskosten nicht davonlaufen. Aber die ehrliche Antwort hat eine Bedingung: Wenn die Software das Jahrzehnt gar nicht erleben soll, zahlen Sie nicht dafür. Für einen Wegwerf-Prototyp ist Langlebigkeit die falsche Investition.

Sind Microservices der Weg zu Langlebigkeit? Nicht von sich aus, und für mittelgroße Systeme oft das Gegenteil. Verteilung fügt Betriebs- und Kopplungskosten hinzu, die nur ein konkretes Problem — unabhängige Skalierung, organisatorische oder regulatorische Grenzen — rechtfertigt. Ohne dieses Problem verkürzt Verteilung die Lebensdauer eher, als sie zu verlängern.

Wie viel Dokumentation braucht es? So viel wie nötig, um das Warum der langsamen Dinge zu bewahren — Entscheidungen, Grenzen, Betrieb. Nicht mehr. Dokumentation über schnellen Implementierungsdetails ist am nächsten Tag falsch und schadet dann.

Können Sie garantieren, dass Software zehn Jahre läuft? Nein, und wer es garantiert, hat die Frage nicht verstanden — garantieren lässt es sich nicht, weil die Welt sich ändert. Entwerfen lässt es sich, und benennen lässt sich, was es brechen würde: verlorenes Warum, wuchernde Kopplung, unbekannte Fehlerfälle, Komplexität ohne Problem. Wir bauen gegen diese vier. Das ist keine Garantie, aber der Unterschied zwischen Hoffnung und Ingenieurarbeit.

Weiterführend

Dieser Text ist die Grundlage; die folgenden vertiefen einzelne Entscheidungen daraus:

• Reversibilität vor Vorhersage — wie man Entscheidungen unter Unsicherheit trifft, wenn man die Zukunft nicht kennt.
• Der modulare Monolith — wann er die richtige Wahl ist, und wann nicht.
• Domänenlogik unabhängig vom Framework — warum Geschäftsregeln nicht in den Controller gehören.
• Testen, wo Fehler teuer sind — eine Teststrategie ohne Dogma.
• Beobachtbarkeit ab Tag eins und Für den Fehlerfall entwerfen — Betrieb als Teil des Entwurfs.
• Ausgereifte Technik vor Neuheit — warum wir nicht der Mode folgen.
• Laravel oder Symfony — ein ehrlicher Architekturvergleich als konkretes Beispiel einer tragenden Technikwahl.

Grundlage von allem sind das Batunet-Manifest und die Batunet Engineering Method.

Der Test für langlebige Software ist einfach zu stellen und schwer zu bestehen: Könnte jemand, der heute nicht dabei war, das System in fünf Jahren sicher ändern? Wenn ja, war die Arbeit gut. Man wird es ihr nicht ansehen — sie läuft einfach.