- Software ist am Tag der Fertigstellung am gesündesten. Die Umgebung verändert sich weiter, auch wenn Ihr Code stehen bleibt.
- Vier Ereignisse treffen jedes System: brechende Abhängigkeit, abgelaufenes Zertifikat, geänderte Schnittstelle, Personalwechsel.
- Bei selbstgebauter Software ist der Bus-Faktor fast immer eins. Es fehlt dann nicht der Code, sondern das Wissen um seine Voraussetzungen.
- Eine Seite Dokumentation je System, ein fester Quartalstermin und eine benannte Vertretung decken den größten Teil des Risikos ab.
Das Werkzeug läuft. Drei Wochen Arbeit, ein paar Dutzend Anläufe mit einem Sprachmodell, und die Tabelle, die seit Jahren durch vier Abteilungen wandert, ist abgelöst. Das Team nutzt die neue Lösung täglich. Niemand vermisst die Tabelle.
Das ist ein echter Erfolg, und er wird regelmäßig unterschätzt. Was ebenso regelmäßig unterschätzt wird, ist der Tag, an dem dieses Werkzeug zum ersten Mal nicht mehr läuft. Er kommt selten in den ersten Wochen, meistens irgendwann nach einem halben Jahr, und er kommt fast nie zu einem passenden Zeitpunkt. Die Frage ist dann nicht, ob jemand das reparieren kann. Die Frage ist, wer.
Warum die ersten Monate nichts beweisen
Software ist am Tag ihrer Fertigstellung am gesündesten. Alle Bibliotheken sind auf dem Stand von heute, die Zertifikate frisch, die Schnittstellen aktuell, und die Person, die alles gebaut hat, hat das gesamte System noch im Kopf. Unter diesen Bedingungen läuft nahezu jede Lösung stabil, auch eine improvisierte.
Diese Bedingungen halten nicht. Betrieb ist kein Zustand, sondern ein Gleichgewicht zwischen Verfall und Pflege. Die Umgebung verändert sich weiter, auch wenn Ihr Code stehen bleibt: Browser ändern ihr Verhalten, Anbieter schalten alte Versionen ab, Sicherheitslücken in Abhängigkeiten werden bekannt. Ein System, an dem niemand etwas ändert, wird nicht stabiler. Es entfernt sich nur langsam von der Welt, in der es funktioniert hat.
Der verlässliche Test: Nehmen Sie sich das fertige Werkzeug sechs Wochen nach der Inbetriebnahme vor und versuchen Sie, alle Abhängigkeiten auf den aktuellen Stand zu bringen. Nicht weil es nötig wäre, sondern um zu sehen, wie viel Aufwand ein Routinevorgang kostet. Was jetzt zwei Stunden dauert, dauert in zwei Jahren zwei Tage.
Vier Ereignisse, die jedes System treffen
Die Ausfälle selbstgebauter Software folgen einem erstaunlich engen Muster. Es sind im Wesentlichen vier Ereignisse, und keines davon hat etwas mit der Qualität Ihres Codes zu tun. Sie treffen gut gebaute Systeme genauso.
| Ereignis | Typischer Zeitpunkt | Woran es scheitert |
|---|---|---|
| Brechende Abhängigkeit | 6 bis 18 Monate | Ein Paket bekommt eine neue Hauptversion, das alte wird nicht mehr gepflegt |
| Abgelaufenes Zertifikat | 3 bis 12 Monate | Die automatische Erneuerung war nie eingerichtet oder ist still gescheitert |
| Geänderte Schnittstelle | 12 bis 24 Monate | Ein Anbieter schaltet eine Programmierschnittstelle ab, die Ankündigung ging an eine Adresse, die niemand liest |
| Personalwechsel | jederzeit | Der Code ist noch da, die Entscheidungen dahinter sind es nicht |
Die ersten drei sind planbar. Sie haben ein Datum, und mit etwas Disziplin steht dieses Datum in einem Kalender. Das vierte ist das eigentliche Problem, weil es alle anderen verstärkt: Ein abgelaufenes Zertifikat ist eine Aufgabe von zwanzig Minuten, wenn jemand weiß wo es liegt. Ohne dieses Wissen ist es ein halber Tag Suche in einem System, das niemand mehr erklären kann.
Bus-Faktor eins
Der Bus-Faktor beschreibt, wie viele Personen ausfallen müssen, bis ein System niemand mehr betreuen kann. Bei selbstgebauter Software ist die Antwort fast immer eins. Das ist keine Nachlässigkeit, sondern die natürliche Folge der Arbeitsweise: Eine Person hat die Anforderung verstanden, die Struktur entschieden, den Code erzeugen lassen, geprüft und ausgeliefert. Es gab nie einen Grund, jemandem etwas zu erklären.
KI-Unterstützung ändert daran weniger, als viele erwarten. Sie verschiebt das Problem nur. Ein Sprachmodell kann fremden Code hervorragend erklären, und wer sich in ein bestehendes System einarbeiten muss, spart damit erhebliche Zeit. Was es nicht rekonstruieren kann, sind die Entscheidungen: warum dieser Grenzwert bei fünfzig liegt, welche Alternative verworfen wurde und welche Annahme über die Daten getroffen wurde, die nirgends steht. Genau daran scheitert Wartung, nicht am Lesen des Codes. Wie weit eine automatisierte Analyse bei bestehenden Systemen trägt und wo sie an Grenzen stößt, haben wir in was KI in einer Codebase findet ausführlich beschrieben.
Der günstigste Zeitpunkt, den Bus-Faktor zu erhöhen, ist der Tag der Fertigstellung. Eine Seite Text reicht: Was macht das System, welche Zugänge braucht es, wo läuft es, was passiert wenn es ausfällt, und welche drei Entscheidungen würde man beim nächsten Mal anders treffen. Dieses Dokument ist in einer halben Stunde geschrieben und später durch nichts zu ersetzen.
Was Wartung tatsächlich kostet
In der Softwareentwicklung gilt seit Jahrzehnten die Beobachtung, dass über die gesamte Lebensdauer eines Systems der Betrieb deutlich mehr Aufwand verursacht als der ursprüngliche Bau. Für selbstgebaute Werkzeuge gilt das in verschärfter Form, weil die Bauzeit dank KI-Unterstützung stark gesunken ist, die Wartung aber nicht im gleichen Maß.
Das ist der Punkt, an dem viele Rechnungen kippen. Wenn ein Werkzeug in drei Wochen statt in drei Monaten fertig ist, wirkt der Eigenbau unschlagbar günstig. Rechnet man drei Jahre Betrieb dazu, verschiebt sich das Bild deutlich. Nicht immer zu Ungunsten des Eigenbaus, aber oft genug, dass die Rechnung vorher aufgestellt gehört. Die gleiche Überlegung stellt sich bei jeder größeren Entwicklungsentscheidung, wie wir in Software selbst bauen: die Entscheidungen davor gezeigt haben.
Dazu kommt ein Effekt, der sich schlecht in Stunden ausdrücken lässt: Aufgeschobene Wartung wird nicht billiger, sondern teurer. Wer drei Hauptversionen einer Bibliothek überspringt, macht nicht einen großen Sprung statt drei kleiner. Er macht einen Sprung, bei dem alle drei Änderungen gleichzeitig wirken und sich gegenseitig verdecken. Was das langfristig mit einem System macht, ist unter dem Begriff technische Schulden gut beschrieben.
Drei Wege, den Betrieb zu regeln
1. Intern, mit benannter Verantwortung
Eine Person ist zuständig, eine zweite kennt das System so weit, dass sie im Notfall einspringt. Dazu ein fester Termin pro Quartal, an dem Abhängigkeiten aktualisiert und Zertifikate geprüft werden. Das funktioniert gut, solange die zuständige Person im Haus bleibt und der Termin nicht der erste ist, der bei Arbeitsdruck ausfällt.
2. Extern, mit klarer Vereinbarung
Der Betrieb wandert zu einem Dienstleister, intern bleibt eine Ansprechperson für fachliche Fragen. Sinnvoll, sobald das Werkzeug in einem Ablauf steckt, dessen Ausfall Geld kostet. Wichtig ist dabei weniger die Reaktionszeit im Vertrag als die Frage, ob jemand das System vor dem ersten Ausfall einmal vollständig gelesen hat. Für diese Übergabe und die laufende technische Verantwortung ist ein Interim CTO oder eine begleitende Softwareentwicklung der übliche Weg.
3. Bewusst mit Verfallsdatum
Nicht jedes Werkzeug muss drei Jahre laufen. Ein Skript, das eine einmalige Umstellung begleitet, darf danach verschwinden. Diese Entscheidung ist völlig legitim, aber sie muss vorher getroffen werden und alle Beteiligten müssen sie kennen. Der gefährliche Fall ist das Werkzeug, das als Provisorium gedacht war und nach zwei Jahren in vier Abteilungen steckt, ohne dass jemand diesen Übergang bemerkt hat.
Was Sie jetzt tun können
Wenn in Ihrem Unternehmen selbstgebaute Werkzeuge laufen, beantworten Sie für jedes davon drei Fragen: Wer ist zuständig, wann wurde zuletzt etwas aktualisiert, und was passiert konkret, wenn es morgen ausfällt. Die Werkzeuge, bei denen Ihnen auf eine dieser Fragen keine Antwort einfällt, sind die, um die Sie sich zuerst kümmern sollten. Nicht weil sie schlecht gebaut sind, sondern weil sie unbeobachtet in etwas Wichtiges hineingewachsen sind.
Seit dem Erscheinen dieses Artikels ist der Software-Fahrplan als eigenes Format dazugekommen. Er setzt genau vor dem Punkt an, den dieser Text beschreibt: Technologie, Datenhaltung, Hosting und Sicherheit werden festgelegt, bevor die erste Zeile entsteht. Dazu gehört auch die Frage, wer das fertige System später betreibt und was passiert, wenn diese Person nicht mehr da ist. Wer seine Software mit einer Coding-KI selbst umsetzen will, klärt damit die Entscheidungen vorab, die sich hinterher nur noch teuer korrigieren lassen.
Der Aufwand dafür ist überschaubar. Eine Seite Dokumentation je System, ein fester Quartalstermin und eine benannte Vertretung decken den größten Teil des Risikos ab. Das ist deutlich weniger Arbeit als der erste ungeplante Ausfall, und man kann es sich aussuchen.