Beantwortet von der Redaktion von Business.Digital Stand
Technische Schulden, auf Englisch Technical Debt oder kurz Tech Debt, bezeichnen die angesammelten Konsequenzen von Abkürzungen, schlechten Entscheidungen und aufgeschobener Arbeit in einem Softwareprojekt. Wie bei einem finanziellen Kredit: Man bekommt jetzt schnell etwas, zahlt aber später mehr zurück.
Der Begriff wurde 1992 vom Software-Ingenieur Ward Cunningham geprägt. Er beschrieb damit eine bewusste Entscheidung: Manchmal ist es sinnvoll, eine schnelle, nicht optimale Lösung zu bauen, wenn der Business-Druck es erfordert. Wichtig ist, diese Schuld später zu tilgen. Das Problem entsteht, wenn niemand das tut.
Wie Tech Debt entsteht
Zeitdruck ist die häufigste Ursache. Ein Feature muss bis zum Launch fertig sein, also wird eine pragmatische Lösung gewählt, die funktioniert, aber nicht gut strukturiert ist. “Das räumen wir nachher auf” sagt jeder, der unter Zeitdruck arbeitet. Meistens passiert das Aufräumen nicht.
Auch fehlende Erfahrung spielt eine Rolle. Entwickler, die am Anfang ihrer Karriere stehen, treffen Entscheidungen, die erfahrenere Entwickler anders getroffen hätten. Das ist normal, wird aber zum Problem, wenn kein erfahrener Blick draufschaut und niemand Refactoring einplant.
Wachsende Anforderungen ohne angepasste Architektur sind ebenfalls ein häufiger Treiber. Was für zehn Nutzer gebaut wurde, muss auf einmal hunderttausend Nutzer bewältigen. Die ursprüngliche Architektur hält nicht, aber statt sie grundlegend anzupassen, werden Workarounds gebaut.
Was passiert, wenn Tech Debt zu groß wird
Bei kleinen Mengen ist Tech Debt kein Problem. Jedes Softwareprojekt hat ihn. Wenn er aber zu groß wird, verlangsamt sich die Entwicklung merklich. Jede neue Funktion ist schwieriger zu bauen, weil der Code so komplex und verflochten ist. Bugs werden häufiger, weil Änderungen an einer Stelle unerwartete Auswirkungen an anderer Stelle haben.
Im schlimmsten Fall führt massiver Tech Debt zu einem kompletten Rewrite, also einer Neuentwicklung der gesamten Anwendung. Das ist teuer und zeitaufwendig.
So prüfen wir technische Schulden im Health Check
Vier Dimensionen, jede mit einer konkreten Frage.
Software-Aktualität: Läuft noch die CMS- oder Framework-Version von vor drei Jahren? Je größer die Lücke zur aktuellen Version, desto teurer wird das Nachziehen, und irgendwann ist es kein Update mehr, sondern eine Migration.
Code-Qualität: Ist der Code lesbar und dokumentiert? Könnte eine neue Entwicklerin ihn verstehen, oder liegt das Wissen bei einer einzigen Person? Code, den nur einer versteht, ist ein Betriebsrisiko.
Architektur: Wurde über Jahre mit Workarounds erweitert, statt einmal sauber umzubauen? Wie viele Werte stehen fest im Code, die eigentlich konfigurierbar sein müssten?
Testabdeckung: Gibt es automatisierte Tests, die anzeigen, wenn eine Änderung etwas Bestehendes bricht? Ohne Tests entsteht Angst vor Änderungen, und Angst vor Änderungen ist der teuerste Zustand in einem Softwareprojekt.
Am Ende steht keine Note, sondern eine Reihenfolge: Was zuerst, was kann warten, was rechtfertigt einen Neubau statt weiterer Reparaturen.
Wenn du eine Softwarelösung entwickeln lässt und von Anfang an auf Codequalität setzen willst, oder wenn du bestehenden Code von einer Agentur übernommen hast und wissen willst, wie es darin aussieht, sprechen wir das gerne durch. Buche einen kostenlosen Termin.