Technische Schulden
Wenn Software teuer wird
Die meisten Unternehmen können ziemlich genau sagen, was ihre Software gekostet hat. Entwicklung, Lizenzen, Hosting oder Wartungsverträge stehen schließlich auf jeder Rechnung.
Es gibt allerdings einen Kostenfaktor, der dort nicht auftaucht und trotzdem über Jahre enorme Auswirkungen haben kann: technische Schulden.
Der Begriff klingt zunächst etwas abstrakt. Tatsächlich steckt dahinter aber ein Problem, das uns bei bestehenden Softwareprojekten regelmäßig begegnet.
Die Anwendung funktioniert grundsätzlich. Im Alltag gibt es kaum Beschwerden. Erst wenn neue Funktionen hinzukommen oder bestehende Prozesse angepasst werden sollen, wird deutlich, dass sich im Hintergrund einiges angesammelt hat.
Plötzlich dauert eine kleine Änderung mehrere Tage. Ein scheinbar einfacher Wunsch zieht unerwartet viele Anpassungen nach sich. Oder niemand traut sich mehr, bestimmte Bereiche der Software anzufassen, weil nicht klar ist, welche Folgen eine Änderung haben könnte.
Genau das sind typische Anzeichen technischer Schulden.
Was technische Schulden eigentlich sind
Der Begriff stammt aus der Softwareentwicklung und beschreibt die Folgen kurzfristiger technischer Entscheidungen.
Ein einfaches Beispiel:
Für eine neue Funktion gibt es zwei Möglichkeiten. Die erste Lösung ist sauber aufgebaut, gut dokumentiert und lässt sich später problemlos erweitern. Dafür benötigt sie etwas mehr Zeit.
Die zweite Lösung funktioniert ebenfalls, ist aber schneller umgesetzt. Bestimmte Dinge werden vereinfacht, Tests werden verschoben oder der Code wird an einer Stelle eingebaut, an der er eigentlich nicht hingehört.
Unter Zeitdruck fällt die Entscheidung oft zugunsten der zweiten Variante.
Das ist nicht zwangsläufig falsch.
Schließlich muss Software häufig unter realistischen Rahmenbedingungen entstehen. Termine müssen eingehalten werden, Kunden warten auf neue Funktionen oder gesetzliche Änderungen verlangen kurzfristige Anpassungen.
Problematisch wird es erst dann, wenn aus der Übergangslösung ein Dauerzustand wird.
Nicht jede Abkürzung ist automatisch ein Fehler
Der Begriff "technische Schulden" klingt schnell so, als hätte jemand schlechte Arbeit geleistet.
Ganz so einfach ist es aber nicht.
In vielen Projekten sind pragmatische Entscheidungen völlig sinnvoll.
Ein Start-up möchte möglichst schnell mit einem Produkt an den Markt. Ein Unternehmen muss kurzfristig auf neue Anforderungen reagieren oder eine wichtige Funktion rechtzeitig bereitstellen.
In solchen Situationen ist Geschwindigkeit oft wichtiger als Perfektion.
Entscheidend ist nur, dass allen Beteiligten bewusst ist, welche Konsequenzen diese Entscheidung später haben kann.
Genau wie bei einem Kredit verschwindet die Verpflichtung nicht von allein.
Wer technische Schulden aufnimmt, sollte auch einen Plan haben, sie später wieder abzubauen.
In der Praxis passiert genau das allerdings erstaunlich selten.
Warum technische Schulden entstehen
Software entwickelt sich selten geradlinig.
Während der Entwicklung kommen neue Anforderungen hinzu, Prioritäten ändern sich und Kunden wünschen zusätzliche Funktionen. Gleichzeitig bleibt der Zeitplan meistens derselbe.
Irgendwann fallen dann Sätze wie:
"Das räumen wir später auf."
"Für automatisierte Tests reicht die Zeit gerade nicht."
"Die Dokumentation schreiben wir nach dem Release."
Oder ganz klassisch:
"Hauptsache, es funktioniert erst einmal."
Jeder Entwickler kennt solche Situationen.
Für sich genommen wirken diese Entscheidungen meist harmlos. Schließlich geht es oft nur um eine kleine Vereinfachung.
Das eigentliche Problem entsteht erst mit der Zeit.
Denn Software bleibt selten unverändert. Sie wächst. Neue Funktionen kommen hinzu, bestehende Prozesse werden erweitert und weitere Entwickler arbeiten am Projekt.
Was ursprünglich als kleine Ausnahme gedacht war, wird irgendwann Teil der eigentlichen Architektur.
Die Folgen zeigen sich meist erst Jahre später
Kaum ein Unternehmen würde von sich behaupten, technisch verschuldete Software einzusetzen.
Dafür gibt es einen einfachen Grund.
Technische Schulden machen sich selten plötzlich bemerkbar.
Sie entstehen schleichend.
Am Anfang läuft die Anwendung völlig unauffällig. Auch kleinere Erweiterungen lassen sich noch problemlos umsetzen.
Erst nach einigen Jahren verändert sich das Bild.
Neue Entwickler benötigen deutlich länger, um sich einzuarbeiten. Änderungen ziehen unerwartete Nebeneffekte nach sich. Fehler treten häufiger auf und jede neue Funktion scheint mehr Aufwand zu verursachen als die vorherige.
Von außen wirkt es oft so, als würde die Entwicklung einfach teurer werden.
Tatsächlich liegt das Problem häufig woanders.
Nicht die neue Funktion ist komplizierter geworden.
Die bestehende Software ist komplizierter geworden.
Und genau das macht technische Schulden so tückisch.
Sie tauchen auf keiner Rechnung auf.
Sie erscheinen in keinem Projektplan.
Sie sorgen aber dafür, dass praktisch jede zukünftige Entwicklung ein Stück aufwendiger wird.
Wenn jede Änderung zum Risiko wird
Gut entwickelte Software hat eine wichtige Eigenschaft:
Sie lässt sich verändern.
Neue Funktionen können ergänzt werden, bestehende Abläufe können angepasst werden und Fehler lassen sich beheben, ohne dass an anderer Stelle neue Probleme entstehen.
Mit zunehmenden technischen Schulden wird genau das schwieriger.
Bereiche, die ursprünglich voneinander getrennt waren, wachsen immer stärker zusammen. Kleine Änderungen wirken sich plötzlich auf völlig andere Funktionen aus. Entwickler müssen erst lange analysieren, welche Auswirkungen eine Anpassung überhaupt haben könnte.
Wir erleben das regelmäßig bei älteren Projekten.
Eigentlich soll nur eine Kleinigkeit geändert werden. Nach kurzer Analyse stellt sich jedoch heraus, dass davon fünf weitere Bereiche betroffen sind.
Nicht weil die neue Funktion besonders aufwendig wäre.
Sondern weil die Software über Jahre immer komplexer geworden ist.
Veraltete Frameworks: Die Schulden, die niemand bemerkt
Technische Schulden entstehen nicht nur durch schlecht geschriebenen Code. Ein häufiger Auslöser ist schlicht, dass eine Anwendung über Jahre nicht konsequent gepflegt wird.
Das erleben wir besonders häufig bei älteren PHP-Projekten.
Die Software läuft seit Jahren zuverlässig, es gibt keine offensichtlichen Probleme und deshalb besteht zunächst auch kein Handlungsbedarf. Warum also Zeit und Geld in Framework-Updates investieren?
Die Antwort zeigt sich meist erst später.
Mit jeder neuen Version eines Frameworks werden Sicherheitslücken geschlossen, Fehler behoben und Funktionen verbessert. Wer diese Entwicklung über Jahre ignoriert, verliert nach und nach den Anschluss.
Irgendwann wird aus einem kleinen Versionssprung ein großes Migrationsprojekt.
Hinzu kommt ein weiterer Punkt, der häufig unterschätzt wird: Je älter eine eingesetzte Technologie wird, desto schwieriger wird es, Entwickler zu finden, die sich damit noch gut auskennen. Was heute noch problemlos gewartet werden kann, entwickelt sich in einigen Jahren schnell zum Spezialwissen.
Spätestens dann steigen auch die Kosten.
Automatisierte Tests kosten Zeit – fehlende Tests meistens noch mehr
Kaum ein Thema wird in Softwareprojekten so häufig verschoben wie automatisierte Tests.
Der Grund liegt auf der Hand.
Tests kosten zunächst Zeit. Sie müssen entwickelt, gepflegt und regelmäßig angepasst werden. Unter Termindruck erscheint es deshalb oft sinnvoller, diese Zeit lieber in neue Funktionen zu investieren.
Kurzfristig funktioniert das sogar.
Langfristig sieht die Rechnung allerdings meist anders aus.
Je größer eine Anwendung wird, desto schwieriger lässt sich überblicken, welche Auswirkungen eine Änderung hat. Ohne automatisierte Tests bleibt oft nur der klassische Weg: ausprobieren, klicken und hoffen, dass nichts kaputtgeht.
Das kostet nicht nur Zeit, sondern schafft auch Unsicherheit.
Entwickler werden vorsichtiger. Änderungen dauern länger und nach jedem Release beginnt die Suche nach möglichen Fehlern.
Automatisierte Tests verhindern solche Probleme natürlich nicht vollständig. Sie sorgen aber dafür, dass viele Fehler bereits während der Entwicklung auffallen – und nicht erst beim Kunden.
Gerade bei größeren Anwendungen sind sie deshalb weniger Luxus als eine Investition in die Zukunft.
Dokumentation schreibt niemand gern – vermisst wird sie trotzdem
Dokumentation gehört vermutlich zu den unbeliebtesten Aufgaben in der Softwareentwicklung.
Solange ein Projekt klein ist und immer dieselben Entwickler daran arbeiten, fällt das kaum auf. Jeder kennt die Struktur, weiß, warum bestimmte Entscheidungen getroffen wurden und findet sich auch ohne ausführliche Beschreibungen zurecht.
Schwieriger wird es, wenn sich das Team verändert.
Neue Entwickler müssen sich erst in den bestehenden Code einarbeiten. Externe Dienstleister übernehmen einzelne Bereiche oder ein Projekt wird nach mehreren Jahren wieder erweitert.
Spätestens dann zeigt sich, wie wertvoll eine gute Dokumentation ist.
Dabei geht es nicht darum, jede einzelne Codezeile zu beschreiben.
Viel wichtiger ist, dass nachvollziehbar bleibt, warum bestimmte Entscheidungen getroffen wurden, welche Architektur dahintersteht und wie einzelne Komponenten zusammenspielen.
Fehlt dieses Wissen, beginnt jede Änderung mit einer langen Analysephase.
Zeit, die eigentlich in die Weiterentwicklung fließen sollte.
Eine gute Architektur zahlt sich erst später aus
Über Softwarearchitektur wird oft gesprochen, solange ein Projekt entsteht.
Im Alltag gerät sie dagegen schnell in den Hintergrund.
Dabei entscheidet gerade die Architektur darüber, wie gut sich eine Anwendung in einigen Jahren noch weiterentwickeln lässt.
Ist der Code sauber strukturiert, haben einzelne Komponenten klar definierte Aufgaben. Änderungen bleiben auf einen überschaubaren Bereich beschränkt und neue Funktionen lassen sich vergleichsweise einfach ergänzen.
Fehlt diese Struktur, wächst die Komplexität mit jedem neuen Feature.
Module greifen ineinander, Verantwortlichkeiten verschwimmen und Änderungen haben Auswirkungen an Stellen, an denen niemand damit gerechnet hätte.
Das Problem entsteht nicht von heute auf morgen.
Es entwickelt sich schrittweise – oft über viele Jahre.
Genau deshalb fällt es vielen Unternehmen zunächst gar nicht auf.
Software ist nie wirklich fertig
Viele Unternehmen betrachten Software noch immer wie ein klassisches Bauprojekt.
Nach der Fertigstellung soll sie möglichst viele Jahre unverändert ihren Dienst leisten.
In der Praxis funktioniert moderne Software allerdings anders.
Frameworks entwickeln sich weiter, Sicherheitslücken werden geschlossen, Browser ändern ihr Verhalten und Betriebssysteme bringen neue Anforderungen mit.
Auch gesetzliche Vorgaben verändern sich regelmäßig.
Eine Anwendung, die heute technisch aktuell ist, wird in einigen Jahren zwangsläufig Pflege benötigen.
Das ist kein Zeichen schlechter Entwicklung.
Im Gegenteil.
Regelmäßige Wartung gehört zu professioneller Software genauso selbstverständlich dazu wie Inspektionen bei einem Auto. Niemand würde erwarten, dass ein Fahrzeug zehn Jahre lang ohne Wartung zuverlässig funktioniert.
Bei Software gelten letztlich dieselben Grundregeln.
Wann aus technischer Schuld Legacy Software wird
Nicht jede ältere Anwendung ist automatisch ein Legacy-System.
Viele Anwendungen verrichten auch nach zehn oder fünfzehn Jahren noch zuverlässig ihren Dienst.
Kritisch wird es dann, wenn sich die Software praktisch nicht mehr weiterentwickeln lässt.
Neue Funktionen werden immer aufwendiger. Updates werden aus Angst vor Nebenwirkungen verschoben. Irgendwann entscheidet man sich sogar bewusst gegen Änderungen, weil das Risiko zu groß erscheint.
Spätestens an diesem Punkt entstehen klassische Legacy-Systeme.
Interessanterweise ist Legacy Software häufig nicht die eigentliche Ursache des Problems.
Sie ist vielmehr das Ergebnis jahrelang aufgeschobener technischer Schulden.
Jede kleine Abkürzung war für sich genommen nachvollziehbar.
In der Summe entsteht daraus jedoch ein System, das sich immer schwerer warten und erweitern lässt.
Warum eine komplette Neuentwicklung selten die beste Lösung ist
Wenn Unternehmen erkennen, wie viele technische Schulden sich angesammelt haben, liegt eine Idee oft nahe:
"Wir entwickeln alles neu."
Das klingt zunächst verlockend.
Schließlich könnten alle alten Probleme auf einen Schlag verschwinden.
In der Praxis ist eine komplette Neuentwicklung allerdings häufig die teuerste und gleichzeitig riskanteste Lösung.
Bestehende Anwendungen enthalten meist viele Jahre Fachwissen, Sonderfälle und gewachsene Geschäftsprozesse. Dieses Wissen steckt oft nicht in der Dokumentation, sondern direkt in der Software.
Bei einer Neuentwicklung muss all das erneut verstanden und umgesetzt werden.
Deshalb ist ein schrittweises Refactoring häufig der sinnvollere Weg.
Dabei wird die bestehende Anwendung nach und nach modernisiert. Bereiche mit besonders hohen technischen Schulden werden gezielt verbessert, ohne dass das gesamte System ersetzt werden muss.
Das reduziert Risiken und verteilt den Aufwand über einen längeren Zeitraum.
Außerdem bleibt die Anwendung währenddessen weiterhin produktiv nutzbar.
Technische Schulden kosten nicht nur Entwickler Zeit
Wenn über technische Schulden gesprochen wird, denken viele zunächst an ein Problem der IT-Abteilung. Tatsächlich betreffen sie aber das gesamte Unternehmen.
Je komplexer eine Anwendung wird, desto länger dauern neue Entwicklungen. Funktionen, die früher innerhalb weniger Stunden umgesetzt werden konnten, benötigen plötzlich mehrere Tage oder sogar Wochen.
Das wirkt sich direkt auf Projekte aus.
Budgets steigen, Termine verschieben sich und neue Ideen bleiben länger liegen, weil zunächst bestehende Probleme gelöst werden müssen.
Hinzu kommt ein weiterer Aspekt, der oft erst spät auffällt: Unternehmen verlieren an Flexibilität.
Während Wettbewerber neue Anforderungen schnell umsetzen oder auf veränderte Marktbedingungen reagieren können, bindet die eigene Software immer mehr Ressourcen. Nicht weil neue Funktionen besonders kompliziert wären, sondern weil jede Änderung zunächst durch eine über Jahre gewachsene Struktur hindurch muss.
Genau deshalb sind technische Schulden längst kein rein technisches Thema mehr. Sie beeinflussen unmittelbar, wie schnell sich ein Unternehmen weiterentwickeln kann.
Der erste Schritt: Transparenz schaffen
Technische Schulden lassen sich nur abbauen, wenn man weiß, wo sie überhaupt entstanden sind.
Genau daran scheitert es in vielen Unternehmen.
Die Software funktioniert schließlich noch. Warum also Zeit in eine technische Analyse investieren?
Erst wenn größere Änderungen anstehen oder die Entwicklung immer langsamer wird, beginnt die Suche nach den Ursachen.
Dabei lohnt sich eine Bestandsaufnahme oft deutlich früher.
- Wie aktuell sind die eingesetzten Frameworks?
- Werden Bibliotheken regelmäßig aktualisiert?
- Gibt es automatisierte Tests?
- Ist die Architektur nachvollziehbar aufgebaut?
- Existiert eine Dokumentation oder steckt das Wissen ausschließlich in den Köpfen einzelner Entwickler?
Solche Fragen liefern meist schon ein recht klares Bild vom technischen Zustand einer Anwendung.
Dabei geht es nicht darum, jede einzelne Schwachstelle sofort zu beseitigen.
Viel wichtiger ist es, Prioritäten zu setzen.
Nicht jede technische Schuld muss morgen zurückgezahlt werden. Manche Bereiche funktionieren problemlos und verursachen nur wenig Aufwand. Andere bremsen jede Weiterentwicklung aus und sollten deshalb zuerst modernisiert werden.
Kontinuierliche Pflege statt großer Kraftakt
Viele Unternehmen beschäftigen sich erst dann mit ihrer Software, wenn größere Probleme auftreten.
Dabei ist genau das meist der teuerste Zeitpunkt.
Wer seine Anwendung regelmäßig pflegt, Frameworks aktuell hält und kleinere technische Verbesserungen kontinuierlich einplant, verhindert, dass sich überhaupt ein großer Berg technischer Schulden aufbaut.
Das ist vergleichbar mit der Wartung einer Maschine.
Kleine Inspektionen kosten Zeit und Geld, verhindern aber oft teure Reparaturen oder lange Ausfallzeiten.
Bei Software funktioniert dieses Prinzip ganz ähnlich.
Regelmäßige Pflege ist deutlich günstiger als eine aufwendige Komplettsanierung nach vielen Jahren.
Qualität ist kein Selbstzweck
Manchmal entsteht der Eindruck, Entwickler würden über sauberen Code oder gute Architektur sprechen, weil sie technische Perfektion anstreben.
In der Realität geht es um etwas ganz anderes.
Sauber entwickelte Software spart langfristig Geld.
Sie lässt sich schneller erweitern, einfacher warten und verursacht deutlich weniger Risiken bei Änderungen.
Natürlich bedeutet das nicht, dass jedes Projekt von Anfang an perfekt umgesetzt werden muss. Das wäre weder wirtschaftlich noch realistisch.
Entscheidend ist vielmehr, dass kurzfristige Kompromisse bewusst eingegangen werden und später auch wieder zurückgebaut werden.
Genau das unterscheidet eine pragmatische Entscheidung von dauerhaft wachsenden technischen Schulden.
Fazit
Technische Schulden gehören zur Softwareentwicklung dazu. Kaum ein Projekt kommt ganz ohne Kompromisse aus.
Problematisch wird es erst, wenn aus kurzfristigen Entscheidungen dauerhafte Strukturen entstehen.
Veraltete Frameworks, fehlende Tests, unzureichende Dokumentation oder über Jahre gewachsene Abhängigkeiten machen sich oft erst bemerkbar, wenn eine Anwendung erweitert werden soll. Dann steigen Entwicklungsaufwand und Kosten häufig deutlich schneller, als es von außen nachvollziehbar erscheint.
Unsere Erfahrung zeigt: Die eigentliche Ursache liegt selten in einer einzelnen schlechten Entscheidung. Viel häufiger sind es viele kleine Abkürzungen, die über Jahre nie wieder aufgeräumt wurden.
Deshalb lohnt es sich, den technischen Zustand einer Anwendung regelmäßig zu überprüfen und notwendige Modernisierungen nicht immer weiter aufzuschieben.
Wer technische Schulden konsequent abbaut, sorgt nicht nur für sauberen Code. Er schafft die Grundlage dafür, dass Software auch in einigen Jahren noch wirtschaftlich weiterentwickelt werden kann.
Denn eine gute Software erkennt man nicht daran, dass sie heute funktioniert. Entscheidend ist, ob sie sich auch morgen noch ohne großen Aufwand an neue Anforderungen anpassen lässt.